Deploy to Production

What is Deployment?

During development, your app runs on localhost:3000 or localhost:8080. Only you can access it from your own machine. Deployment is the process of putting your app on a real server with a real domain so that anyone on the internet can use it. It is the final step that turns your project into a product.

On your local machine, you type grit dev and everything just works. But your users need to access your app from their browsers — they cannot connect to your laptop. A VPS gives your app a permanent home on the internet with a public IP address. You point your domain name to that IP, and suddenly myapp.com loads your Grit application.

The grit deploy Command

Grit gives you a single command that handles the entire deployment pipeline — building your code, uploading it to your server, configuring the process manager, and setting up HTTPS. Here is the full command:

grit deploy --host deploy@server.com --domain myapp.com

That's it. One command, and your app is live. Let's break down every flag:

What Happens During Deploy

When you run grit deploy, a 5-step pipeline executes automatically. Understanding each step helps you debug deployment issues and customize the process when needed.

Here is the exact build command Grit runs internally during Step 1:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o bin/myapp ./cmd/server

Let's break this down:

systemd — The Process Manager

Once your binary is on the server, something needs to keep it running. You cannot just SSH in and type ./myapp — the process would die the moment you close your terminal. That's where systemd comes in.

Grit automatically generates a systemd service file for your app. Here is what it looks like:

[Unit]
Description=myapp
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/myapp
Restart=on-failure
RestartSec=5
EnvironmentFile=/opt/myapp/.env

[Install]
WantedBy=multi-user.target

Let's understand each section:

Caddy — Reverse Proxy with Auto-TLS

Your Go app listens on port 8080, but users expect to visit https://myapp.com (port 443). Something needs to sit between the user's browser and your app to handle HTTPS, compress responses, and add security headers. That something is Caddy.

Here is the Caddy configuration that Grit generates:

myapp.com {
    reverse_proxy localhost:8080
    encode gzip
    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }
    log {
        output file /var/log/caddy/myapp.log {
            roll_size 10mb
            roll_keep 5
        }
    }
}

Let's understand what each directive does:

Environment Variables for Deploy

Typing --host, --domain, and --key every time you deploy is tedious and error-prone. Instead, you can set environment variables in your .env file and Grit will read them automatically.

DEPLOY_HOST=deploy@server.com
DEPLOY_KEY_FILE=~/.ssh/id_rsa
DEPLOY_DOMAIN=myapp.com

With these variables set, deploying becomes a single word:

grit deploy

No flags needed. Grit reads DEPLOY_HOST, DEPLOY_KEY_FILE, and DEPLOY_DOMAIN from your .env file. You can still override any variable with a flag — flags take priority over environment variables.

Maintenance Mode During Deploy

Sometimes you need to take your app offline briefly during a deployment — for example, when running database migrations that change table structures. Grit provides maintenance mode for this:

grit down              # 503 for all requests
grit deploy --host ... # Deploy new version
grit up                # Back online

When maintenance mode is active, every API request receives a 503 Service Unavailableresponse with a friendly message. Your frontend can detect this status code and show a"We'll be right back" page instead of confusing error messages.

Docker Deployment (Alternative)

The grit deploy command is designed for simple VPS deployment — one server, one app. For more complex setups where you need to run your API, database, and cache all together in isolated containers, Docker with Docker Compose is the way to go.

Grit scaffolds a docker-compose.prod.yml file for production Docker deployment:

services:
  api:
    build: ./apps/api
    ports:
      - "8080:8080"
    env_file: .env
    depends_on:
      - postgres
      - redis
  postgres:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
  redis:
    image: redis:7-alpine

This defines your entire production stack: the API service (built from your Go code), PostgreSQL for the database, and Redis for caching and job queues. Docker Compose starts all three together and handles networking between them automatically.

To deploy with Docker, copy your project to the server and run:

docker compose -f docker-compose.prod.yml up -d --build

Production Checklist

Before going live, walk through this checklist. Missing any of these items could lead to security vulnerabilities, data loss, or embarrassing errors in front of real users.

Updating a Deployed App

Your app is live and users are using it. Now you need to ship a bug fix or a new feature. How do you update? Just run grit deploy again:

# Make your code changes locally
# Test them thoroughly
grit deploy

Grit runs the same 5-step pipeline: rebuild the binary, upload it, and restart the systemd service. The restart happens so quickly that users experience near-zero downtime. systemd stops the old process and starts the new one in milliseconds.

Here is the typical update workflow:

Summary

You have completed the entire Grit Web course series. Let's recap what you learned in this final course: