marina.toml

Marina works out how to build and start most repos on its own. When you want to be explicit, put a marina.toml at the root:

[processes]
web = "node server.js"

[build.env]
VITE_API_URL = "https://api.example.com"

The file is optional, every key in it is optional, and it is read on the next deploy. Commit it and push; there is nothing to click.

The start command

[processes]
web = "node server.js"

web is the process that serves HTTP traffic. Declare it when your app builds fine but starts the wrong thing, or does not start at all. With it declared there is no guessing, every deploy.

worker is accepted here and not yet run, so declaring one does nothing today. Any other name fails the deploy.

Variables your build needs

This is the one most people come for. Vite, Create React App and Next.js bake certain variables into the bundle while npm run build runs. A variable that only exists at runtime is not there yet, so the build either fails or ships an app pointing at nothing.

[build.env]
VITE_SUPABASE_URL = "https://xyz.supabase.co"
VITE_API_URL = "https://api.example.com"

These are build-time only. Your running app reads the config vars you set with marina env set, not these. Two lists, two jobs: one is baked into the bundle, the other is the environment the process starts with.

Never put a real secret here. marina.toml is committed, so anything in it is as visible as your code. A VITE_ variable ends up readable in the JavaScript you ship anyway, so it belongs here. A database password or a private API key belongs in marina env set, never in a file in your repo.

Values must be quoted strings. Up to 32 variables, 1024 characters each; names are letters, digits and underscores, not starting with a digit.

If you build with a Dockerfile

A Dockerfile at the root is used automatically. Point at a different one:

[build]
dockerfile = "docker/Dockerfile.prod"

[build.env] works here too: each variable arrives as a build argument, so declare a matching ARG to use it.

ARG VITE_API_URL
RUN npm run build

Overriding the build

When there is no Dockerfile and the detected build command is not the one you want:

[build]
command = "npm run build:production"

Everything the file can hold

Key	What it does
processes.web	The command that starts your app.
build.env	Variables present while your app builds.
build.command	Override the detected build command.
build.dockerfile	Use a Dockerfile at a path other than the root.

Mistakes fail loudly

An invalid marina.toml stops the deploy and names what to fix, rather than shipping something broken quietly. Unquoted value, unknown process name, invalid variable name, a command declared but empty: each one is its own message.