Deployment options

info

This page describes how Blaster can be deployed beyond local development, from a simple self-hosted server through to a full Kubernetes and GitOps setup.

Blaster game series

1. Blaster arcade game
2. Blaster setup
3. Blaster gameplay and features
4. Blaster architecture
5. Blaster deployment - You are here

For full GitOps detail and production runbooks, see the Blaster GitOps series.

1. Common building blocks

Regardless of where you deploy Blaster, you will use the same core pieces:

• A built Next.js application (npm run build).
• A running PostgreSQL 15 database with the Blaster schema applied.
• Environment variables for database access and Clerk authentication.
• The same migration system (npm run migrate) to keep the schema in sync.

The differences are in how you provision infrastructure, manage secrets, and automate deployments.

2. Option: self-hosted server

For a single VM or bare-metal host:

1. Install Node.js and PostgreSQL.
2. Create the blaster_game database and apply migrations with npm run migrate.
3. Configure environment variables (for example via a systemd unit file, .env file, or process manager).
4. Build and start Blaster:

npm run build
npm run start

You then place a reverse proxy (such as NGINX or Caddy) in front of the Node.js process to provide TLS and friendly hostnames.

This option is simple and works well when you only need one instance and are comfortable managing the host directly.

3. Option: Kubernetes with GitOps

Blaster is primarily designed to run in Kubernetes with a GitOps workflow. The high-level pattern is:

1. Build a Docker image for Blaster in CI (for example via GitLab CI and Kaniko).
2. Tag images with meaningful names (for example prod-YYYYMMDD.BUILD).
3. Store manifests for the app and database under k8s/prod/ in the Blaster repo (Deployment, Service, StatefulSet, Secrets, ConfigMaps, Ingress, certificates).
4. Let FluxCD watch the repo and apply changes in the cluster based on Kustomizations and ImageUpdateAutomation policies.
5. Use SOPS and age to keep Secrets encrypted in Git.
6. Run migrations via an initContainer that executes npm run migrate before the main app container starts.

Typical Kubernetes pieces for Blaster include:

• A StatefulSet and Service for PostgreSQL.
• A Deployment and Service for the app itself.
• An Ingress pointing at the app service.
• Certificates via cert-manager and, optionally, Cloudflare Origin CA.
• Registry Secrets for pulling private images.
• Flux sources, Kustomizations, ImageRepository, ImagePolicy, and ImageUpdateAutomation objects in a separate GitOps repo.

The cluster view is documented in the Blaster GitOps runbooks; this page stays focused on how the application behaves in that environment.

4. Image automation

In the Kubernetes and GitOps setup, Blaster uses image automation rather than manual edits:

• CI builds and pushes images such as registry.reids.net.au/games/blaster:prod-20251116.62.
• Flux discovers new tags that match the policy.
• Image automation updates the image references in the Blaster manifests in Git.
• Flux reconciles the updated manifests into the cluster.

This keeps production updates traceable and avoids hand-editing YAML in the cluster. It also integrates tightly with the migration initContainer, so schema changes and code changes move together.

5. Security and hardening notes

Whichever deployment path you choose:

• Keep secrets out of images and source control. Use .env.local only for local dev; use Secrets elsewhere.
• Use .dockerignore to ensure .git/, .env*, editor configs, and local scripts are not copied into images.
• Prefer parameterised SQL and server-side database access only.
• In Kubernetes, add resource limits, health probes, and basic NetworkPolicy objects so the game is not a special case in the cluster.

For a deeper security review of Blaster’s container and cluster deployment, see the security notes and hardening guidance in the Blaster GitOps and security review documents.