vertracloud.config file is optional and only pre-fills the creation flow: name, description,
main file, memory, commands and subdomain. Once created, the application uses what’s saved in the
dashboard.
The vertracloud.config file
vertracloud.config is a text file at the root of the .zip, with one KEY=value per line.
Unknown keys are ignored.
vertracloud.config
Keys are case-insensitive, and a value may be wrapped in single or double quotes. Lines starting with
# are comments; the CLI also accepts ;, but the API reads ; lines as ordinary text, so prefer #. When you create an application with vertra upload, the CLI reads NAME, MEMORY, MAIN, VERSION, SUBDOMAIN, START and LANGUAGE from the file, but not DESCRIPTION or BUILD: pass --description, and set the build command in Settings → General. Restoring a snapshot whose vertracloud.config is larger than 64 KB or 64 lines fails with INVALID_CONFIG.
vertracloud.config.json is also accepted, with lowercase keys: name, description,
main, memory, build, start, subdomain and language. The language is set by LANGUAGE= in the text file and by "language" in the JSON file.
Which value wins?
When reading the.zip, the creation flow uses the vertracloud.config value when it exists,
and falls back to the platform’s suggestion, which reads package.json and the project’s
dependencies. After that, any field can be edited in the following steps. Start and build
commands you edit by hand aren’t overwritten if you swap the .zip.
Without LANGUAGE, the platform detects the language from the manifest files at the root of the project, checking each ecosystem before package.json: a Python, PHP or Ruby project with a front-end package.json stays Python, PHP or Ruby. MAIN=./src/index.js (with the leading ./) is accepted.
Without MAIN, the platform looks for the main file via main and the start script in
package.json, and then by common names (index.js, server.js, main.py, app.py, main.go,
src/main.rs, main.ts, index.php, index.html and others).
vertracloud.config is not stored among the application’s files. It’s discarded once the
.zip is extracted, and regenerated with the dashboard’s current values when you download the
project or create a snapshot. That’s why a downloaded or restored project always carries the
current configuration.Advanced configuration: start and build commands
The start command replaces the default way of starting the runtime from the main file. The build command runs after dependency installation and before start, on every deploy: code upload, GitHub deploy, Force build, and changing the command itself. A plain restart doesn’t run the build again.
If the build fails, the application doesn’t come up (
BUILD_FAILED); if it runs past 10 minutes,
the deploy is interrupted (BUILD_TIMEOUT). A new application is still created, stopped, with the
build output in its logs — fix the files and start it again. The build environment gets twice the application’s
memory, between 1 GB and 4 GB.
Port and web publishing
An application with web publishing must listen on port 80, on0.0.0.0. The platform
already sets PORT=80 and HOST=0.0.0.0 in the container, so reading process.env.PORT (or
your language’s equivalent) works. That’s why PORT and HOST are reserved and can’t be set
by you.
Without web publishing, the application doesn’t receive inbound traffic and runs in the
background, like a bot or a worker. Publishing requires 512 MB of
memory, and can be turned on or off at any time. Turning it on or off recreates the container, so
the application restarts. When turned off, the subdomain is released and someone else can
register it.
Environment variables
Environment variables are injected into the container when it starts and are encrypted at rest. You set them in Settings → Environment variables, via the API, the CLI or MCP.
If the
.zip has a .env.production, .env.production.local, .env.local or .env (in that
order of preference), the creation flow pre-fills the variables from it. Review the values before
creating.
Application limits
The full table per plan is in Plans and limits.