Deployment
Nimbus compiles to a single binary, making deployment straightforward on any platform. Use nimbus deploy for one-command deploys to Fly.io, Railway, AWS, or Docker — or follow the manual steps for Render, Netlify, and systemd.
One-Command Deploy
Nimbus provides a built-in deploy command that handles Dockerfile generation, vendoring (for local replace directives), and platform-specific setup:
nimbus deploy fly # Deploy to Fly.io
nimbus deploy railway # Deploy to Railway
nimbus deploy aws # Build for AWS (Docker image)
nimbus deploy docker # Build Docker image locally
When no target is given, Nimbus prompts interactively for target, app name, region, and migrations.
Deploy Configuration
Create a config file with nimbus make:deploy-config or add deploy.yaml manually:
# nimbus deploy config
target: fly
app_name: my-app
# service: my-app # Railway only; defaults to app_name
region: iad
# Run migrations before each deploy (Fly.io release_command)
migrations: true
# Env vars to set as secrets (from .env, never committed)
# secrets:
# - DATABASE_URL
# - REDIS_URL
# Worker processes (Fly.io process groups, Railway services)
# workers:
# - command: queue:work
# scale: 1
Requirements: Install the platform CLI before deploying — fly for Fly.io, railway for Railway, docker for AWS/Docker. Railway will prompt for login and project link on first deploy.
If your go.mod has a replace pointing to a local path (e.g. ../nimbus), Nimbus runs go mod vendor before deploy so remote builds succeed.
Build for Production
Compile an optimized binary:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app .
The resulting app binary is self-contained with no runtime dependencies. Copy it to your server along with your .env, views/, and public/ directories.
Environment Variables
Set production values in your .env file or export them in the environment:
PORT=8080
APP_ENV=production
APP_NAME=myapp
DB_DRIVER=postgres
DB_DSN=host=localhost user=myapp password=secret dbname=myapp_prod port=5432 sslmode=disable
Environment variables set in the system take precedence over .env values.
Reverse Proxy with Nginx
Run Nimbus behind Nginx for TLS termination, static file serving, and load balancing:
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Docker Deployment
Use nimbus deploy docker to build, or create a Dockerfile manually. Nimbus generates one if missing — it uses a multi-stage build, supports vendoring for local replace directives, and copies all runtime files (views/, public/, config/, etc.) into the final image:
# Nimbus Go app - multi-stage build
FROM golang:1.26-alpine AS builder
WORKDIR /app
RUN apk add --no-cache gcc musl-dev
COPY go.mod go.sum ./
COPY . .
RUN if [ -d vendor ]; then \
CGO_ENABLED=1 go build -mod=vendor -ldflags="-s -w" -o /app/server .; \
else \
go mod download && CGO_ENABLED=1 go build -ldflags="-s -w" -o /app/server .; \
fi
# Minimal runtime image
FROM alpine:3.19
RUN apk add --no-cache ca-certificates
WORKDIR /app
COPY --from=builder /app/server .
COPY --from=builder /app/. .
RUN rm -rf vendor go.mod go.sum
ENV PORT=8080
EXPOSE 8080
CMD ["./server"]
Build and run the container:
nimbus deploy docker
# or manually:
docker build -t myapp .
docker run -d -p 8080:8080 --env-file .env myapp
Systemd Service
On Linux servers, use a systemd unit to manage the process:
[Unit]
Description=Nimbus App
After=network.target
[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/app
Restart=on-failure
RestartSec=5
EnvironmentFile=/opt/myapp/.env
[Install]
WantedBy=multi-user.target
Enable and start the service:
sudo cp myapp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp
Render
Render offers free-tier web services with automatic deploys from GitHub. Your app must bind to 0.0.0.0 and use the PORT environment variable (Render uses port 10000 by default).
In the Render Dashboard, click New > Web Service, connect your repo, and set:
Build Command: go build -o app .
Start Command: ./app
For Inertia apps, add a build step to compile the frontend first:
Build Command: npm install && npm run build && go build -o app .
Start Command: ./app
Add environment variables (e.g. APP_ENV, DB_DSN) in the Render dashboard. Attach a PostgreSQL database from the Render add-ons if needed. Every push to your branch triggers a new deploy.
Fly.io
Fly.io runs your app on lightweight VMs globally. Install flyctl, then deploy with one command:
nimbus deploy fly
Or manually: fly auth login, fly launch. Fly detects your Go app and creates a fly.toml config. Set secrets with fly secrets set:
fly secrets set APP_ENV=production
fly secrets set DB_DSN="postgres://..."
Your app will be live at https://your-app.fly.dev. Add Fly Postgres for a managed database.
Railway
Railway offers simple deploys with automatic builds from your Dockerfile. Install the Railway CLI, then:
nimbus deploy railway
On first deploy, Railway will prompt for login (opens browser) and project link. Set app_name and optionally service in deploy.yaml. Add environment variables (e.g. DATABASE_URL) in the Railway dashboard.
Netlify
Netlify is optimized for static sites and JAMstack. For full Nimbus apps (persistent Go HTTP server), use Render or Fly.io instead.
You can use Netlify in two ways:
- Static site: If your app serves only static files (e.g. built Inertia assets), connect your repo and set the publish directory to
public/. Build command:npm run build(for Inertia). - Go serverless functions: Netlify supports Go functions (AWS Lambda). This requires adapting your Nimbus handlers to the Lambda request/response format — use Render or Fly.io for a simpler full-stack deployment.
For a typical Nimbus app with Inertia, deploy the Go backend to Render, Fly.io, or Railway and optionally use Netlify only for hosting the built frontend if you split the architecture.
Deployment Checklist
- Set
APP_ENV=productionin your environment. - Use a process manager (systemd, Docker, or supervisor) to auto-restart on crash.
- Put Nimbus behind a reverse proxy for TLS and static assets.
- Keep
.envout of version control — use secrets management in CI/CD. - Ensure
views/,public/, and other runtime files are included (Docker deploy copies them automatically). - Run database migrations before starting the new release.