Skip to main content

Deployment

This page covers best practices and recommendations for deploying your Base Worker in production environments.

Reverse Proxy & HTTPS​

danger

Never expose your Worker directly to the public internet.

  • Use a reverse proxy (Nginx, Traefik, Caddy, Apache) to:
    • Terminate SSL/TLS (HTTPS)
    • Forward requests securely to your Worker

Example Nginx config:

server {
  listen 443 ssl;
  server_name your-worker.example.com;

  ssl_certificate /etc/ssl/certs/your-cert.pem;
  ssl_certificate_key /etc/ssl/private/your-key.pem;

  location / {
    proxy_pass http://localhost:3000;
    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;
    # Optional: Basic Auth
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
  }
}

Docker as a Service​

In production, we recommend using Docker and configuring it as a service. Here's how to configure your Worker container as a service with systemd (compatible with Debian, Ubuntu, Fedora, CentOS 7+, RHEL 7+, Rocky, AlmaLinux, Arch Linux, etc.).

  1. Stop the Docker container if it was launched.

  2. Create a service:

    touch /etc/systemd/system/andera-worker.service

  3. Complete it with your service configuration:

    [Unit]
    Description=Andera Worker
    Requires=docker.service
    After=docker.service

    [Service]
    Type=oneshot
    WorkingDirectory=/var/www/andera-worker
    ExecStart=/usr/bin/docker compose up -d
    ExecStop=/usr/bin/docker compose down
    RemainAfterExit=yes

    [Install]
    WantedBy=multi-user.target

  4. Activate the service:

    sudo systemctl daemon-reexec
    sudo systemctl enable andera-worker
    sudo systemctl start andera-worker

Authentication and Secure Communication​

  • All requests to Worker endpoints (except /health public info) require the AUTH_KEY.
  • When the Load Balancer communicates with a Worker (for /task), it provides:
    • Authorization: <AUTH_KEY> (the Worker's AUTH_KEY)
    • x-lb-auth: <LB_AUTH_KEY> (the Load Balancer's LB_AUTH_KEY)
  • For direct client calls to /task, only Authorization: <AUTH_KEY> (the Worker's AUTH_KEY) is required.
  • Sensitive endpoints like /logs and authenticated /health (which displays more information than the unauthenticated public version) require valid authentication headers.
  • When the Worker is used in HTTP, it connects to the Load Balancer via ws://. When using HTTPS, it connects via wss://.

Secrets​

  • Never commit secrets to git.
  • Use environment variables for all sensitive config (keys, passwords, etc.).
  • Rotate keys regularly.

Network Security​

  • Restrict access to Worker ports using firewalls or security groups.
  • Only allow trusted sources (Load Balancer, internal services) to connect.

Checklist for Production​

  • Use HTTPS via a reverse proxy
  • Set strong, unique AUTH_KEY and LB_AUTH_KEY
  • Use environment variables for secrets
  • Monitor logs and health endpoints
  • Restrict network access
  • Regularly update dependencies and images

Tip: For cloud deployments, use managed SSL, secrets managers, and autoscaling as provided by your platform.