Part 8: Production Patterns¶

Harden your deployment with memory limits, health check tuning, database backups, and rollback strategies.

What you'll learn¶

Setting memory limits per service — and why cpu does nothing
Tuning health check intervals and thresholds, and the minimums the schema enforces
How a failed deploy is contained
Planning database backup strategies
Rolling back to a previous version
Fully deleting an application and everything it owns

What you'll need¶

The full application from Part 7 deployed and working

Resource limits¶

Stop a single service from consuming all of a host's memory:

database:
  enabled: true

deploy:
  - name: backend
    container: backend
    port: 3000
    resources:
      memory: 512m
    health_check:
      path: /health

resources.memory needs a unit suffix

Write 512m, 1g or 262144k. A bare number is interpreted as bytes, so memory: 512 gives the container 512 bytes and it dies instantly. 512mb is not a recognised suffix either — use 512m.

resources.cpu is accepted but does nothing

The schema parses a cpu: value without complaint, and no code path ever applies it. It is not a CPU limit and setting it changes nothing about how your container runs. Omit it. Memory is the only container resource AppMecca actually enforces.

Sizing guidance

Start with 256m for lightweight Node.js services and 512m for services with database connections. Watch real usage with mecca app stats todo-app before tightening limits.

A type: spa service must never go below 32m — that is a hard validation error, because below it the nginx worker is killed silently while the master survives.

Health check tuning¶

The default health check works for most cases, but production services benefit from tuned parameters:

deploy:
  - name: backend
    container: backend
    port: 3000
    health_check:
      path: /health
      interval: 15
      timeout: 5
      healthy_threshold: 2
      unhealthy_threshold: 3
      startup_timeout: 180

Parameter	Default	Range	Description
`path`	`/health`	—	HTTP path probed
`interval`	30	5-300	Seconds between checks
`timeout`	5	2-120	Seconds before a check is considered failed
`healthy_threshold`	2	2-10	Consecutive successes to mark healthy
`unhealthy_threshold`	3	2-10	Consecutive failures to mark unhealthy
`startup_timeout`	120	30-600	Seconds a new container gets to become healthy during a deploy

The thresholds have a minimum of 2

Setting healthy_threshold or unhealthy_threshold to 1 is rejected at validation time, so the "flapping" advice below is enforced by the schema rather than left to you. There is no retries or start_period field.

Aggressive intervals

Setting interval too low can cause flapping during normal load spikes. Start conservative and tighten based on observed behaviour. Raise startup_timeout — not interval — when a service is simply slow to boot.

Failed deploys and rollback¶

Tune the health check so a bad deploy is caught quickly — it is the health check that decides whether a new container is allowed to take over:

deploy:
  - name: backend
    container: backend
    port: 3000
    health_check:
      path: /health
      interval: 10
      unhealthy_threshold: 3

AppMecca does not monitor an app after a successful deploy and revert it. What protects you is blue/green: the incoming container must pass its health check before the load balancer is switched to it, so a failing deploy leaves the running version untouched and is simply marked failed. To go back to an earlier build, redeploy its tag — mecca build list -a <app> to find a succeeded build's tag, then mecca app deploy <app> --image-tag <tag> --no-build.

Database backup strategy¶

Create backups before every deployment and on a regular schedule. A bundle captures the database and every declared drive:

# Pre-deployment backup
mecca app backup todo-app -d "pre-deploy $(date +%Y%m%d-%H%M)"

# Deploy
mecca build trigger -g git@github.com:yourorg/todo-app.git

List backups and note the bundle prefix you may need:

mecca app backups todo-app
mecca app backups todo-app --json
mecca app backups todo-app -n 50     # more than the default 20

Download a bundle for local inspection:

mecca app download todo-app <bundle-prefix>

Automate backups

Add a pre-deploy backup to your CI/CD pipeline so every production deployment has a corresponding snapshot to roll back to.

Manual rollback¶

A rollback is a deploy that targets an older image with --no-build — there is no separate rollback command. First list the available versions, then deploy the known-good tag:

mecca build list -a todo-app
mecca app deploy todo-app --image-tag abc1234 --no-build

Roll back database changes¶

If the failed deployment included a migration, restore the database from a pre-deployment bundle as a separate step:

mecca app backups todo-app                   # list available bundles
mecca app restore todo-app <bundle-prefix>   # restore DB (+ drives)

Database restore is destructive

Restoring replaces the database's current contents with the backup — any data written after that backup is lost. Verify the bundle with mecca app backups first. See Rolling Back.

Skip the confirmation prompt¶

--force skips the interactive confirmation, which is what you want in a scripted emergency rollback:

mecca app deploy todo-app --image-tag abc1234 --no-build

Monitor your app¶

mecca app show todo-app              # Per-service status and URLs
mecca app stats todo-app             # Live memory and CPU per container
mecca app stats todo-app --history   # Daily aggregates
mecca status todo-app                # Service health and uptime
mecca status incident                # Recent incidents

For deployment troubleshooting, mecca debug gathers configured variables, recent deploy errors, per-service health and resolved URLs in one shot:

mecca debug todo-app
mecca debug todo-app --json

Full application cleanup¶

When you are completely done with an application, delete everything it owns — the database (backed up, then dropped), the built images in AppMecca's image registry, the app's build configuration, stored secrets, collected logs, and every registry row:

mecca app delete todo-app --force

This is irreversible

mecca app delete --force is a full purge and cannot be undone. Make sure you have downloaded any backups you need first. mecca app unregister is the same command under a different name — it is not a lighter-weight option; use mecca app undeploy to stop an app without destroying anything.

Summary¶

Over these eight tutorials you have built a complete production-grade deployment:

Part	What you learned
1	Basic deployment lifecycle
2	Managed PostgreSQL with migrations
3	Multi-container monorepo builds
4	SPA runtime config injection
5	Background workers with Redis
6	Feature branch deployments
7	Service-to-service URLs and `visibility`
8	Production hardening and rollback

Your todo application now has a SvelteKit frontend, Express API, PostgreSQL database, Redis-backed workers, an auth service, and production-grade health checks gating every blue/green cutover. Every piece is deployed, managed, and observable through mecca.