Deploy Elixir and Phoenix on Nodion

Deploy Elixir and Phoenix step by step

1. Generate the release files Nodion builds your app with mix release. In a Phoenix project, mix phx.gen.release adds what you need for that: a Release module with a migrate function and the scripts bin/server and bin/migrate. Commit the generated files.

   mix phx.gen.release

2. Read the config at runtime and listen on IPv4 A project from mix phx.new already has a config/runtime.exs that reads PORT, SECRET_KEY_BASE, DATABASE_URL and PHX_HOST in production. Nodion's app instances use IPv4, so set the endpoint's ip to {0, 0, 0, 0}: config/runtime.exs

   config :my_app, MyAppWeb.Endpoint,
     url: [host: host, port: 443, scheme: "https"],
     http: [ip: {0, 0, 0, 0}, port: port],
     secret_key_base: secret_key_base

3. Build assets without Node.js The Elixir build has no Node.js. Phoenix 1.7 and later use standalone esbuild and Tailwind binaries, and Nodion runs your assets.deploy alias during the build. If your asset pipeline calls npm, switch it to these tools or deploy with a Dockerfile. mix.exs

   "assets.deploy": [
     "tailwind my_app --minify",
     "esbuild my_app --minify",
     "phx.digest"
   ]

4. Run migrations from the release Mix is not in the run image, so migrations run through the release, which Nodion builds into /layers/nodion_elixir/release/release. Its bin/migrate script from step 1 calls Release.migrate. A release: line in a Procfile runs once per build before the new version starts; if it fails, the running version stays live. Procfile

   release: /layers/nodion_elixir/release/release/bin/migrate

5. Create the app, the database and the secrets Create an application from your GitHub, GitLab, Bitbucket or Gitea repository in the region EU Central and keep the build strategy on Buildpacks. Create a PostgreSQL database in the same region and attach it on the Environment tab: it arrives as DATABASE_URL on the next deploy. Add SECRET_KEY_BASE from mix phx.gen.secret as a secret and set PHX_HOST to the domain your users open. PORT is set by Nodion.

Good to know

• Pin Elixir and ErlangNodion reads elixir and erlang from .tool-versions, Elixir also from .elixir-version. The elixir: requirement in mix.exs is a range and pins nothing. Without a pin you get Elixir 1.20 on OTP 28.
• Start command and health checkNodion starts bin/<app> start from the release, with the app name from mix.exs, and sets PHX_SERVER=true so the endpoint serves HTTP. Traffic moves once / answers with 2xx or 3xx; if / needs a login, set another health check path in the app settings.

What Nodion runs for you

• Deploys without downtime Push to your branch and Nodion builds a new release. Traffic switches once the new instances answer their health check; a failed release leaves the running one in place. Apps with a local volume restart instead, because the disk belongs to one instance.
• Databases next to the app Managed PostgreSQL, pgvector, MySQL, Valkey and ClickHouse in the same region. Attached databases arrive as DATABASE_URL, REDIS_URL or CLICKHOUSE_URL.
• Previews per pull request Turn on previews and pull requests from your repository get their own app with its own URL and fresh, empty databases, created automatically or by hand. Forks and bot pull requests are skipped.
• Workers, cron jobs and scaling Run workers as extra processes of the same app, schedule jobs on the Cron tab, and scale every process to up to 16 instances.
• Release step With buildpacks, a Procfile release: line runs with every new build. Dockerfile apps, and redeploys or rollbacks to an earlier image, use a release command set on the app itself, which also takes precedence over the Procfile line. On static sites a release step runs in an image that holds only the built files.
• Logs and metrics Build, release and runtime logs plus CPU, memory, disk and network metrics for every instance in the dashboard.
• Domains and HTTPS A default hostname with HTTPS from the first deploy; your own domains get certificates automatically.

Further reading

• Dockerfile vs Buildpacks: Which One Should You Use? Both turn your code into a container image. What differs is who writes the build steps, and that decides control, maintenance and security updates.
• Cloud Native Buildpacks Explained Buildpacks turn your source code into a container image without a Dockerfile. What they are, and how they work.

Elixir and Phoenix on Nodion: questions and answers