4 Container Configuration

The container setup determines how the container is run at start and what critical information is needed to run. The result of this information, or how this information is used, is a runtime OCI container specification in JSON format.

The information that is needed is:

1. User and group The user and group to run the container as (can be root). This should be provided as an integer, for example: user: 1000 group: 1000
2. Entrypoint The container entrypoint is what is started when the container starts. This is usually an entry point script and arguments. For example: docker-entrypoint.sh redis-server --bind 127.0.0.1
3. Working directory The default working directory for the container.
4. Environment variables See special section on environment variables below.
5. Persistent mount points The storage points that contain the data that needs to be saved.
6. Temporary mount points These are the locations the container uses for small files it needs to run. These temporary mount points are stored on in-memory drives.
7. Health check What health check to perform to know if the application has fully started.

How to get this information

A lot of the container setup is already baked into the container image. You can get this information by running the following command. Note that you need to do a docker pull of a hosted container first, if you have not done this already.

docker inspect <container name> --format='{{.Config}}'

For example

docker inspect fenxchat-api:client-postgres --format='{{.Config}}'

Other information

Other information can be found by looking at the documentation for the application. Be careful. LLMs often make mistakes and return environment variables, for example, that do not actually exist.

Environment variables determine critical runtime information, like how to connect to the database or, if needed, the domain at which the application is accessed.

Difference between image environment variables and runtime environment variables

Image environment variables are built into the image. They are static, but the container needs this information to run. The docker inspect command usually gives you all the information needed.

Runtime environment variables determine how to run the application, for example the database connection, port, etc.

1. Application listens on 0.0.0.0 (all IPv4 addresses)
2. Application listens on port 8080
3. Connecting to database
   1. Also see the standard database containers Bubl already has defined. For Postgres, for example, this is:
      1. host: 127.0.0.1
      2. port: 5432
      3. username: app domain, like n8n
      4. password: app domain, like n8n (note: this will change in the future)
4. All containers in a Bubl run behind a reverse proxy for protection. Some applications require environment variables to function correctly when running behind a reverse proxy. Examples are:
   1. The domain, which can be set to a template variable {{.BublAppUrl}} and will be replaced by the app Bubl domain of the Bubl it is started in.
   2. The fact that the reverse proxy is serving the application as https even though the application container serves unencrypted http traffic to the proxy.

LLMs often make mistakes in choosing the environment variables to set certain settings, even after asking to verify. Always verify with the container documentation if environment variables actually exist.

Below are all the environment variables needed for N8n.

Image env vars

"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"NODE_VERSION=22.19.0",
"YARN_VERSION=1.22.22",
"NODE_ICU_DATA=/usr/local/lib/node_modules/full-icu",
"NODE_ENV=production",
"N8N_RELEASE_TYPE=stable",
"SHELL=/bin/sh",

Runtime env vars

"N8N_LISTEN_ADDRESS=0.0.0.0",
"N8N_PORT=8080",
"WEBHOOK_URL=https://{{.BublAppUrl}}",
"N8N_PATH=/",
"N8N_HOST={{.BublAppUrl}}",
"N8N_PROTOCOL=https",
"N8N_EDITOR_BASE_URL=https://{{.BublAppUrl}}",
"N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true",
"N8N_DIAGNOSTICS_ENABLED=false",
"DB_TYPE=postgresdb",
"DB_POSTGRESDB_HOST=127.0.0.1",
"DB_POSTGRESDB_PORT=5432",
"DB_POSTGRESDB_DATABASE=n8n",
"DB_POSTGRESDB_USER=n8n",
"DB_POSTGRESDB_PASSWORD=n8n"

Most containers have a specific folder where they store their persistent information.

For example, for the application Docmost this is /app/data/storage.

Most applications have one persistent storage folder; some containers have more.

Bubl only needs to know which folders need to be persistent. The storage location is managed automatically.

The information that is needed:

List of folders inside the container that need to be stored as persistent storage

Most containers need temporary writable file locations to store state information. This information is deleted when the application stops. For security and performance reasons, Bubl stores this temporarily in memory, which is best practice. Unfortunately, what folders are used as tmp storage can sometimes be hard to find. Often, it depends on the programming language used, for example Node.js. (Note: we plan to create more standard templates for this in the future.)

The information that is needed:

List of folders inside the container that need to be stored as tmp storage

Using a common best practice, Bubl does a health check to see if the application has fully started. We need to know how to validate if the application is up. Often, this can be done by requesting a certain URL. Information needed:

Type of health check: URL or command

Health check: the actual URL to call or command to execute

Expected response: the response that tells if the application is up

Examples