Backend Deployment Quick Reference A quick guide to common commands used for managing backend deployments across different environments using the unified deploy.sh script.

​
📦 Deployment Script

The backend service includes a flexible deployment script deploy.sh that supports Podman, Buildah, and Kaniko (GitOps), removing the dependency on Docker Desktop.

​
Usage

# Standard deployment (interactive menu)
./scripts/deploy.sh [environment]

# Example: Deploy to Production
./scripts/deploy.sh production

​
Build Options

When running the script, you will be prompted to choose a build method:

​
1. Local Build (Podman/Buildah)

  • Tool: Automatically detects and uses buildah (Linux) or podman (Mac/Windows).
  • Environment: Runs on your local machine.
  • Cross-Platform: Supports building for different architectures (e.g., M1 Mac -> Intel Server). 
    # Build for Intel/AMD64 on an M1 Mac
export DOCKER_PLATFORM=linux/amd64
./scripts/deploy.sh production
  • Best for: Fast, iterative development loops.
  • Requirement: podman or buildah must be installed locally.
    Authentication: To push images to GHCR, ensure you are logged in: 
    echo $GHCR_TOKEN | podman login ghcr.io -u <your-username> --password-stdin

​
2. Remote Build (Kaniko)

  • Tool: Triggers a Kaniko Job inside your Kubernetes cluster.
  • Environment: Runs on the cluster nodes (e.g., Raspberry Pi).
  • Best for:
    • Deploying from devices without local build tools (e.g., lightweight laptops).
    • Ensuring architecture compatibility (builds on the target architecture).
    • Reducing local resource usage.
  • Requirement:
    • kubectl configured to point to the cluster.
    • ghcr-secret exists in the namespace (for pushing to GHCR).
    • GITHUB_TOKEN environment variable must be exported (for private repo cloning).
  • Cross-Platform: Kaniko runs on the cluster architecture by default. To force a specific platform: 
    export DOCKER_PLATFORM=linux/amd64
./scripts/deploy.sh production

​
3. Skip Build

  • Action: Skips the build/push step and proceeds directly to Kustomize updates.
  • Best for: Redeploying the current version or updating k8s configs without code changes.

​
Deployment Methods

After the build phase, you can choose how to apply changes:
MethodDescriptionUse Case
Directkubectl apply -k ...Immediate updates, hot-fixing.
GitCommits changes to GitStandard GitOps flow (ArgoCD verifies and syncs).
BothApplies & CommitsImmediate fix + ensuring Git state is consistent.

​
🧪 Local Testing (Optional)

If you need to spin up the stack locally for testing: 
# Using Podman Compose (recommended)
podman-compose -f docker-compose.test.yml up

# Test a specific version with environment variable
VERSION=a1b2c3d podman-compose -f docker-compose.test.yml up
The test environment runs the backend on port 8081 (to avoid conflict with your normal dev server) and sets up temporary PostgreSQL and NATS instances.

​
🤖 CI/CD Automation

Deployments are automated via GitHub Actions (.github/workflows/backend-k8s-deploy.yml) triggered by pushes to specific branches:
BranchTarget EnvironmentDeployment Method
developDevelopmentGitOps Sync
uatUATGitOps Sync
stagingStagingGitOps Sync
mainProductionGitOps Sync

​
Kustomize Preview

# Preview production manifests
kubectl kustomize k8s/overlays/production

​
Pod Management

# Watch pods in production
kubectl get pods -n production -w

# Check logs
kubectl logs -n production -l app=backend --tail=100 -f

​
📊 Resource Allocation Sheet

EnvironmentReplicasCPU (Req/Lim)Memory (Req/Lim)
Development150m / 200m64Mi / 256Mi
UAT2100m / 500m128Mi / 512Mi
Production5200m / 1000m256Mi / 1Gi

​
🚨 Emergency Rollback

To rollback a failed production deployment: 
# Using ArgoCD CLI
argocd app rollback backend-prod <revision>

# Using kubectl
kubectl rollout undo deployment/prod-backend -n production