Deploy Elixir on Your Own Server

Deploy Elixir and Phoenix applications as compiled releases with automatic HTTPS and managed PostgreSQL. Temps builds the release for you, so no Dockerfile is needed.

Quickstart

From your project root, deploy with your preferred package manager:

npx @temps-sdk/cli up --preset nixpacks-elixir

Temps doesn't detect Elixir projects from mix.exs, so choose the Autopack (Elixir) preset (nixpacks-elixir), as above or under Project → Settings → Build & deploy → Build → Framework.

With that preset, Temps runs mix deps.get --only prod, mix compile, mix assets.deploy (for Phoenix apps with an assets/ directory) and mix release, then starts the release with bin/<app> start on a Debian slim image. The Elixir version comes from the elixir: requirement in mix.exs, and defaults to 1.18. Temps sets MIX_ENV=prod for you.

Phoenix

A Phoenix release only starts its web server when PHX_SERVER is set, and Phoenix's generated config/runtime.exs reads SECRET_KEY_BASE and DATABASE_URL. Set the first two as project variables:

npx @temps-sdk/cli environments vars set PHX_SERVER true -e production

npx @temps-sdk/cli environments vars set SECRET_KEY_BASE "$(mix phx.gen.secret)" -e production

A linked managed PostgreSQL database is injected as POSTGRES_URL, not DATABASE_URL, so change config/runtime.exs to read it:

database_url =
  System.get_env("POSTGRES_URL") ||
    raise "environment variable POSTGRES_URL is missing."

What Temps handles automatically

Custom Dockerfile (optional)

If you want full control over the release build, add your own Dockerfile. For example, a multi-stage build on Alpine:

FROM elixir:1.17-alpine AS build
RUN apk add --no-cache build-base git

WORKDIR /app
ENV MIX_ENV=prod

COPY mix.exs mix.lock ./
RUN mix deps.get --only prod && mix deps.compile

COPY lib ./lib
COPY priv ./priv
COPY config ./config
RUN mix compile && mix release

FROM alpine:3.20
RUN apk add --no-cache libstdc++ openssl ncurses-libs

WORKDIR /app
COPY --from=build /app/_build/prod/rel/my_app ./

ENV PORT=4000
EXPOSE 4000
CMD ["bin/my_app", "start"]

Because this Dockerfile listens on 4000, set the project's port to 4000 under Project → Settings → Build & deploy → Deployment, so the PORT Temps sets matches the port it routes to. Make sure your Phoenix endpoint reads the port from the environment and starts its server:

config :my_app, MyAppWeb.Endpoint,
  url: [host: System.get_env("APP_HOST") || "localhost"],
  http: [ip: {0, 0, 0, 0}, port: String.to_integer(System.get_env("PORT") || "4000")],
  server: true

Platform behavior

These rules apply to every app deployed on Temps, regardless of framework.

Health checks

After your container starts, Temps sends HTTP GET requests to verify it is healthy before routing traffic to it.

• Path: / (the root of your application) by default
• Success: 2 consecutive responses with a 2xx, 3xx, 404 or 405 status code
• Timeout: 300 seconds (5 minutes) for the app to become healthy
• Retry interval: 2 seconds between successful checks, 5 seconds after an error response or a failed connection

Connection errors while the app is still starting are retried without penalty. If the app keeps returning other 4xx or 5xx errors for 60 seconds, the deployment fails. The check runs once, at deploy time. To check a different path, add a .temps.yaml to your repository root:

health:
  path: /health

Only path is used. Other health fields (status, interval, timeout, retries) are accepted but currently have no effect.

Auto-injected environment variables

Temps injects these variables into every deployment automatically:

You do not need to configure these manually. They are available in process.env (Node.js), os.environ (Python), os.Getenv (Go), and the equivalent in other languages.

Next Steps