Phoenix

Nitroship detects Phoenix from a :phoenix dependency in mix.exs. The managed preset builds an Elixir release, runs the Phoenix HTTP endpoint on compute, and publishes priv/static assets to the CDN.

DeployCopy Anchor Link

curl -fsSL https://nitroship.co/install.sh | bash
ntro login

Choose a compute region; there is no default. Select Phoenix explicitly in the deployment root:

{
  "build": {"framework": "phoenix"},
  "compute": {"regions": ["kr-icn"]}
}

ntro apps create my-phoenix-app
ntro deploy . --prod

This preset requires the hosted builder. Remove --local from your deploy command. After deploying, open a dynamic page and a static asset at the URL printed by the CLI.

Build and releaseCopy Anchor Link

Declare Elixir and Erlang/OTP versions in .tool-versions. An explicit erlang entry takes precedence over an -otp-N suffix in the Elixir version; without either, the builder uses its stable OTP default. The generated build uses pinned supported toolchain/base versions nearest your declarations, or stable defaults when none are declared. Commit mix.exs and mix.lock.

The build fetches dependencies, compiles the application, runs mix assets.deploy when that alias is defined, and runs mix release --path /opt/release. The final image runs the release rather than the Mix development server. The generated runtime enables PHX_SERVER=true and configures the endpoint to bind all IPv4 interfaces on $PORT, defaulting to 3000.

Keep runtime configuration in config/runtime.exs, particularly database and endpoint settings. Endpoint discovery expects a conventional Phoenix.Endpoint module in lib/*/endpoint.ex. An umbrella project, custom endpoint/release layout, or additional OS dependencies may need your own Dockerfile.

Static assetsCopy Anchor Link

The build stages priv/static under /nitroship/static. The builder automatically extracts that directory to the CDN before starting the release: priv/static/assets/app.js is served at /assets/app.js. Phoenix pages and APIs still run on compute.

Only public assets belong in the extracted directory; exclude Elixir source and secrets. If priv/static is absent or contains no public files, there is no static CDN output. User uploads are not release assets.

Environment and databaseCopy Anchor Link

Set environment variables for your production configuration:

• SECRET_KEY_BASE for the Phoenix endpoint.
• DATABASE_URL when the application uses Ecto and reads that variable; connect to an external database.
• PHX_HOST when your runtime configuration reads it to construct public URLs. Set it to the deployment or custom hostname, not localhost.
• PHX_SERVER=true is enabled by the generated runtime; keep your endpoint configuration compatible with it.

Do not store durable data in a database file inside the image. If a build step reads configuration, provide its required build-time values separately from runtime values.

Runtime limitsCopy Anchor Link

Generated images run as a non-root user. The instance filesystem is ephemeral; release temporary files, caches, and crash dumps are directed under /tmp. Store uploads in S3 or other object storage, not in priv/static or the release directory.

Nitroship does not automatically run migrations, queue workers, or schedulers. Run your project's release migration task in CI or locally against the external database; the managed startup does not run mix ecto.migrate. Do not assume a separately configured queue worker or scheduler is provisioned for you. Use Cron jobs for scheduled HTTP work and arrange worker execution separately.

Framework selection and Dockerfile escape hatchCopy Anchor Link

build.framework: "phoenix" explicitly selects Phoenix and overrides an automatically discovered Dockerfile. It cannot coexist with build.dockerfile.

Without an explicit framework, Nitroship detects the build as described in How Nitroship chooses a build. For a custom release, native system libraries, or a different process/asset layout, remove build.framework and use your own Dockerfile.