Configure a project

Open a project under Deployments, then choose its Settings pages from the sidebar. Settings describe the desired configuration. A saved change can remain pending until a new release applies it: the sidebar marks each settings page that holds one, and a strip at the top of the page names the changes and links to a deployment already carrying them.

Find the settingCopy Anchor Link

Edit as many fields on a page as you need. A bar appears at the bottom of the window, counts the changes, and says when they apply: immediately, or on your next deployment. Press Save (or ⌘S / Ctrl+S) to save every changed part of the page, or Discard to drop them. A refused field says why under the field and stays unsaved. When a change applies on the next deployment, press Deploy changes in the project header.

Build and startCopy Anchor Link

For a detected repository, the proposed recipe is an editable plan, not a requirement to accept every guessed value. Check the root directory, package manager, build command, output directory, start command, and language version. For a repository Dockerfile, set its path and build stage and review the build inputs it expects. A Compose source keeps its Compose-specific service and variable behavior. Force a clean build builds every layer without the cache.

Use Runtime → Where it listens to set the port the application actually listens on, and Health checks for a readiness check it can answer. A web or static plan needs a readiness check; detection supplies one where it can and Review asks when it cannot. Release strategy shows whether the workload can use Blue / green, which starts a candidate first, or must Stop first. Set memory, CPU, and process limits under Resources; leaving them empty means Docker's unbounded default. Shutdown sets the stop signal, the grace period the container has to exit before it is killed, and a drain period during which the previous release keeps running after traffic has moved, so requests in flight can finish.

Release tasks are ordered commands for work such as migrations. They run in the Release stage, after Build and before the new version starts. Each task's Runs in chooses where:

• Release image runs it once in the image the release built, with its volumes, its runtime variables, and the release-task variables you list. This is the default when the build produces an image. For a Compose project it runs in the primary service's image outside the stack.
• Dashboard shell runs it on the host over the unbuilt source, without the application's dependencies.

Review the command and the variables it receives; it may change data before traffic moves to the new release. A task that fails is recorded in the run with its output and cause.

VariablesCopy Anchor Link

The creation form starts with names found in example files, manifests, and source reads, showing a source hint and an example placeholder where one exists. Check the application's own requirements to decide which values are mandatory and which belong in a browser bundle. Use Generate only where the form offers it for a self-issued secret. Fill in provider-owned secrets yourself; the dashboard does not invent a Stripe, GitHub, or database-provider credential.

Each variable reaches one or more scopes: Build, Runtime, or Release task. Build values for generated recipes are passed through temporary secret mounts. A value intended for browser JavaScript, such as NEXT_PUBLIC_* or VITE_*, is public to website visitors once the application builds it into an asset. Treat it as public even when the dashboard stores it encrypted. A custom Dockerfile or Compose build receives such a value only as a plain value; plan its required inputs explicitly.

Use Variables → Import .env to paste or choose a dotenv file and see, line by line, whether each value is new or replaces the current one before importing. Existing secret values are masked. Reveal and Copy value are audited actions; changing only a variable's scope does not copy its old hidden value into a new editable field. A variable you remove from the desired plan may still be present in the live release until you deploy again.

Save and verifyCopy Anchor Link

After changing build, runtime, variables, or domains, press Deploy changes in the project header. The run checks the saved plan before it builds. If it fails, the run page names the cause where possible, points to the affected setting, and lets you open the build log at the line behind it. See releases and rollback.

To try a risky change without touching the live project, choose Duplicate project… from the project's menu and change the copy instead. See what a duplicate copies.