Skip to main content

Application Config

You can configure an application/function for deployment on Boltic using a boltic.toml/boltic.yaml file. Configuration of builds, environment variables, internet-exposed services, resources, and scale go here.

note

App config is optional and currently can only be used when working with Git repositories. Support for other sources is coming soon.

Ways to get a config file​

  • Create one by hand with help from this reference.
  • Use the Boltic CLI to generate a config file - boltic serverless init

The app name​

The first key/value in any app config file is the application name. For example:

app: "my-application"

Whenever applications are deployed, the system will look for a app config file in the root directory and use the application name in that file.

Region​

Boltic uses the primary_region option to determine where to create new instances of the application, as well as to set the BOLT_APPLICATION_REGION environment variable within the applications it deploys. Replace asia-south1 with the code for your Region of choice.

primary_region: "asia-south1"

Handler​

When deploying a function, the handler key is used to specify the function that will be executed when the function is invoked. The handler key is a string that contains the name of the function and the name of the file that contains the function. For example, if the function is named handler and is contained in a file named index.js, the handler key would be set to index.handler.

note
  • The file containing the function must be in the root directory of the application.
  • The file extension is not required in the handler key.
  • For NodeJS and similar languages, the function must be exported from the file.
handler: "index.handler"

Entrypoint​

When deploying a full fledged application, the entrypoint key is used to specify the file that will be executed when the application is started. If not specified, the system will look for a the following files in the root directory of the application depending on the language:

index.js
note

handler and entrypoint are mutually exclusive. If both are present, an error will be thrown.

entrypoint: "index.py"

Language​

Language is an important part of the configuration file. It is used to determine the runtime environment of the application. The language key is a string that contains the name of the language as well as the version. For example, if the application is written in Python, the language key would be set to python/3. Similarly, if the application is written in NodeJS, the language key would be set to nodejs/18 or nodejs/20.

language: "nodejs/18"

The settings section​

The optional settings section contains key/values concerned with language specific settings. These settings are used to configure the runtime environment of the application. Options for language settings are listed in their respective language sections.

# NodeJS settings
settings:
  nodejs:
    common_js: true

# Python settings
settings:
  python:
    key: value

# Golang settings
settings:
  golang:
    key: value

# Java settings
settings:
  java:
    maven: true
    gradle: false

NodeJS settings​

  • common_js: Set to true if the application uses CommonJS modules. Default is false which indicates the application uses ES modules.

Java settings​

  • maven : Set to true if the application uses Maven. Default is true.
  • gradle : Set to true if the application uses Gradle. Default is false.

The build section​

The optional build section contains key/values concerned with how the application should be built. You can read more about builders in Builders

Use Built-in Builder​

build:
  builtin: dockerfile

The built-in builder is the default builder, invoked when there are no build settings in the boltic.yaml file. This build strategy uses a generic system-generated Dockerfile to build your serverless application. It is the recommended choice for most users who don’t have specific requirements for their build process. Currently the only options for built-in builder is dockerfile .

Specify a Dockerfile​

build:
  dockerfile: "Dockerfile.test"

dockerfile accepts a relative path to a Dockerfile. By default, the system looks for Dockerfile in the application root.

If you already have a working Dockerfile, you can use the dockerfile builder. dockerfile accepts a relative path to a Dockerfile. By default, the system looks for Dockerfile in the application root. If you are familiar with Docker, you’ll be at home with this option. This is the most flexible of the options, but with that flexibility comes the need to write Dockerfiles and the associated quirks of the Docker build system.

Use Buildpacks​

build:
  buildpack_builder: "paketobuildpacks/builder-jammy-base"
  buildpacks:
    - "paketo-buildpacks/nodejs"

The builder "buildpack_builder" uses CNB Buildpacks and Builders to create the application image. These are third party toolkits which can use Heroku compatible build processes or other tools. The tooling is all managed by the buildpacks and buildpacks are assembled into CNB Builders - images complete with the buildpacks and OS to run the tool chains.

In our example above, the builder is being set to use Paketo’s all-purpose builder with the NodeJS buildpack.

Specify a Docker ignore file​

build:
  ignorefile: "./path/.dockerignore"

ignorefile accepts a relative path to a .dockerignore file. By default, the system looks for the .dockerignore file in the application root.

Specify build arguments​

You can pass build-time arguments to both Dockerfile and Buildpack builds:

build:
  args:
    USER: "fynd"
    MODE: "production"

Note that build arguments are not available in the runtime container. If you need build information at runtime - like a Git revision - store it in a file at build time, like:

RUN echo $GIT_REVISION > REVISION

Likewise, application environment variables and secrets are not available to builds.

How Boltic determines the build method​

Here's how Boltic determines how to get the app's Docker image:

  1. If an image is specified, in the build: section of boltic.yaml, use that image, regardless of the presence of a Dockerfile in the working directory.
  2. Otherwise, check the build: section of boltic.yaml and use the method specified there, whether it's a Dockerfile, builtin or a buildpack (but don't use buildpacks if you don't have to; they're brittle, bloated, and prone to change).
  3. Otherwise, if there's a Dockerfile (named exactly Dockerfile or dockerfile) in the application root directory, use that Dockerfile for the build.

The env variables section​

env:
  LOG_LEVEL = "debug"
  RAILS_ENV = "production"
  S3_BUCKET = "my-app-production"

This optional section allows setting non-sensitive information as environment variables in the application’s runtime environment.

Env variable names are strictly case-sensitive and cannot begin with BOLT_ (as this could clash with the runtime environment).

The resources section​

This section defines the compute requirements for the application. This section is optional as resources can be set directly from the console.

The default resource size is shared-cpu-1x (0.1vCPU, 64 MB), if not specified in boltic.yaml, which is the smallest size currently possible. You can request bigger containers for your application depending on your needs.

note
  • Config file settings take priority over console settings.
  • If not configured in the file, console settings are used, else sonsole settings are updated if configured.
resources:
  size: "shared-cpu-1x"
  cpu_kind: "performance"
  cpus: 1
  memory: "1024"
  max_memory: "2048"

size​

The preset size to use as base, like size = "shared-cpu-1x" for example.

note

size is mutually exclusive with cpus and memory.

memory​

The memory to request. It can be expressed with units, like memory = "2GB" or memory = "512mb" for example. The value can also be an integer, like memory = "1024" for example, with MB as the default unit.

max_memory​

The maximum memory to request. It can be expressed in the same way as memory.

cpus​

The number of CPUs to request. The value can be an integer, like cpus = 4 for example, or a float, like cpus = 0.5

cpu_kind​

The kind of CPU to request. The value can be "performance" or "shared". The default is "shared".

The experimental section​

This section is for flags and feature settings which have yet to be promoted into the main configuration.

experimental:
  cmd:
    - "path/to/command"
    - "arg1"
    - "arg2"

cmd​

This overrides the CMD set by the Dockerfile. It should be specified as an array of strings, as seen in the example above.

Sample app config​

Here is a sample app config file with the complete set of options:

warning

This is a sample file and may not work as is. Please replace the values with your own.

# Application name
app: my-sample-application

# Deployment region
region: asia-south1

# Function handler
handler: index.handler

# Entrypoint file
entrypoint: index.py

# Programming language and version
language: nodejs/18

# Language-specific settings
settings:
  nodejs:
    # Indicates whether to use CommonJS modules
    common_js: false
  python:
    # Placeholder for Python-specific settings
    key: value
  golang:
    # Placeholder for Go-specific settings
    key: value
  java:
    # Use Maven for Java builds
    maven: true
    # Do not use Gradle for Java builds
    gradle: false

# Build settings
build:
  # Use a Dockerfile for the build process
  builtin: dockerfile

  # Specify the Dockerfile to use
  dockerfile: Dockerfile.test

  # Specify the buildpack builder
  buildpack_builder: paketobuildpacks/builder-jammy-base
  buildpacks:
    # Use the Python buildpack
    - paketo-buildpacks/python

  # Base image for the build
  image: harbor-core.fynd.engineering/public/samples/python-flask:latest

  # Specify the ignore file
  ignorefile: .gitignore

  # Build arguments
  args:
    # Build argument foo with value bar
    foo: bar
    # Build argument KEY with value VALUE
    KEY: VALUE

# Environment variables
env:
  # Environment variable FOO with value BAR
  FOO: BAR
  # Placeholder for additional environment variables
  key: value

# Resource configuration
resources:
  # Resource size configuration
  size: shared-cpu-1x
  # Type of CPU to use
  cpu_kind: performance
  # Number of CPUs allocated
  cpus: 0.25
  # Memory allocated in MB
  memory: "128"
  # Maximum memory limit in MB
  max_memory: "256"

# Experimental settings
experimental:
  cmd:
    # Command to execute
    - path/to/command
    # First argument for the command
    - arg1
    # Second argument for the command
    - arg2