Skip to content

Deploying a Nomad App

Introduction

Nomad is a lightweight, flexible orchestrator for scheduling containerized and non-containerized workloads. Deploying Nomad with a Dockerfile on Klutch.sh provides reproducible builds, managed secrets, and persistent storage for cluster state—all configured from klutch.sh/app. This guide covers installation, repository prep, a production-ready Dockerfile, deployment steps, Nixpacks overrides, sample API usage, and production tips.


Prerequisites

  • A Klutch.sh account (sign up)
  • A GitHub repository containing your Nomad Dockerfile (GitHub is the only supported git source)
  • Networking access to any external services Nomad will schedule (if applicable)
  • TLS certificates if you secure the HTTP API/UI

For onboarding, see the Quick Start.


Architecture and ports

  • Nomad HTTP API and UI run on internal port 4646; choose HTTP traffic.
  • The gRPC endpoint also uses 4646.
  • Persistent storage is recommended for Nomad data and logs.

Repository layout

nomad/
├── Dockerfile # Must be at repo root for auto-detection
└── README.md

Keep secrets (TLS keys, ACL bootstrap tokens) out of Git; store them in Klutch.sh environment variables.


Installation (local) and starter commands

Validate locally before pushing to GitHub:

Terminal window
docker build -t nomad-local .
docker run -p 4646:4646 \
-e NOMAD_DEV=1 \
nomad-local

Dockerfile for Nomad (production-ready)

Place this Dockerfile at the repo root; Klutch.sh auto-detects it (no Docker selection in the UI):

FROM hashicorp/nomad:1.7
# Default: single-node dev-style agent binding to all interfaces
ENV NOMAD_ADDR=http://0.0.0.0:4646 \
NOMAD_BIND_ADDR=0.0.0.0 \
NOMAD_DEV=true
EXPOSE 4646
CMD ["nomad", "agent", "-dev", "-bind=0.0.0.0", "-http-addr=0.0.0.0:4646"]

Notes:

  • Pin the image tag (e.g., 1.7.x) for stability and upgrade intentionally.
  • For production, replace -dev with server/client configuration and supply a config file via a mounted volume.
  • Add TLS flags (-tls-cert-file, -tls-key-file, -tls-ca-file) if you secure the API.

Environment variables (Klutch.sh)

Set these in Klutch.sh before deploying:

  • NOMAD_ADDR=http://0.0.0.0:4646
  • NOMAD_BIND_ADDR=0.0.0.0
  • NOMAD_DEV=true (set to false and provide config for production)
  • Optional TLS: NOMAD_CACERT, NOMAD_CLIENT_CERT, NOMAD_CLIENT_KEY if you pass them to Nomad flags

If you deploy without the Dockerfile and need Nixpacks overrides:

  • NIXPACKS_START_CMD=nomad agent -dev -bind=0.0.0.0 -http-addr=0.0.0.0:4646

Attach persistent volumes

In Klutch.sh storage settings, add mount paths and sizes (no names required):

  • /opt/nomad — data directory for state, logs, and allocations.

Ensure this path is writable inside the container.


Deploy Nomad on Klutch.sh (Dockerfile workflow)

  1. Push your repository—with the Dockerfile at the root—to GitHub.
  2. Open klutch.sh/app, create a project, and add an app.
  3. Select HTTP traffic and set the internal port to 4646.
  4. Add the environment variables above, including TLS settings if used.
  5. Attach a persistent volume for /opt/nomad sized for your state and logs.
  6. Deploy. Access the Nomad UI/API at https://example-app.klutch.sh (port 4646) and begin managing workloads.

Sample API usage

Check leader status:

Terminal window
curl -X GET "https://example-app.klutch.sh/v1/status/leader"

List nodes:

Terminal window
curl -X GET "https://example-app.klutch.sh/v1/nodes"

Health checks and production tips

  • Add an HTTP probe to /v1/status/leader for readiness.
  • Enforce HTTPS at the edge; forward internally to port 4646.
  • For production, run server/client mode with proper config, ACLs, and TLS; keep secrets in Klutch.sh and rotate them regularly.
  • Monitor /opt/nomad usage; resize before it fills.
  • Pin image versions and test upgrades in staging; back up state before major updates.

Nomad on Klutch.sh combines reproducible Docker builds with managed secrets, persistent storage, and flexible HTTP/TCP routing. With the Dockerfile at the repo root, port 4646 configured, and state persisted, you can orchestrate workloads without extra YAML or workflow overhead.