Skip to Content
We are conducting a survey to learn how startups, SMEs, developers, and technical teams currently host, deploy, and operate software. Take the survey
Infralane
Infralane
ApplicationsBuild and runtime configuration

Build and runtime configuration

The deployment launchpad separates configuration into build, resources, and runtime data. This page explains what each field means.

Repository settings

Branch

The branch identifies the version-control branch to deploy. Production teams often use a protected release branch, while development environments may use a feature or staging branch.

Root directory

The directory within the repository that contains this application. Use / for the repository root. In a monorepo, point it to the relevant subdirectory.

Build settings

Language runtime

For Git deployments, choose from the runtimes currently offered by the form: Node.js, Python, or Go. The runtime selection helps prepare the build environment; your commands still need to match the repository.

Build command

The command that installs or compiles the application. The suggested default is editable. Prefer deterministic commands supported by your project and lockfile.

Start command

The command that starts a web service or worker and remains running. Static sites do not use a start command in the current workflow.

Output directory

For a static site, this is the folder produced by the build. It is relative to the application’s root directory.

Port

For a web service, enter the internal port on which the application listens. Workers do not use a port. The value must be a positive number.

Resource settings

Choose an active resource pool, then set CPU and memory. Memory is entered in MB in the application form. Compare the app allocation with total pool capacity and other applications already using the pool.

Environment variables

Environment variables are key-value pairs made available to the running application. Use clear uppercase keys such as APP_ENV or DATABASE_URL.

Rules for safe use:

  • never put a secret in the key name;
  • verify that values are entered only in the value field;
  • do not print secret values in application logs;
  • rotate a credential if it was exposed;
  • remove unused values to reduce risk and confusion.

The creation form filters out rows without a key. Review every row before deployment.

Application settings can reveal existing runtime values to authorized dashboard users when deliberately unmasked. Share access carefully, and never expose a value during screen sharing or in screenshots.

Persistent volumes

Each volume has:

  • Name — a recognizable identifier without secrets;
  • Mount path — the path where the app reads and writes data, such as /app/data;
  • Size — requested persistent capacity, such as 10GB when accepted by the form.

Do not mount a volume over files the application needs to start unless that behavior is intentional. Design the app to handle an empty volume on first launch and a full volume gracefully.

Review checklist

Before deployment, confirm:

  • the source and exact release version are correct;
  • commands match the selected root directory;
  • the port matches the application listener;
  • CPU and memory fit the pool;
  • required variables are present and secrets are not exposed elsewhere;
  • volume paths and sizes are correct.
Last updated on