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
vertracloud.config.json is also accepted, with lowercase keys: name, description,
main, memory, build, start and subdomain.
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 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, 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). 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 the Pro plan or higher and 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 the Environment step of the creation flow, in the Config tab, 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.