Part 8: Production Patterns¶
Harden your application with memory limits, health check tuning, and backup strategies.
What you'll learn¶
- Setting memory limits per service — and why
cpudoes nothing - Tuning health check parameters, and the minimums the schema enforces
- How AppMecca protects you from a bad deploy (and what it does not do)
- Pre-release database backup and restore workflows
- Rolling back to a specific version
- Cleaning up an application completely
What you'll need¶
- A multi-service app from any previous part (Part 5 or later recommended)
Step 1: Add resource limits and tune health checks¶
Both are configured in the deploy block. Here is a backend service with both:
database:
enabled: true
deploy:
- name: backend
container: backend
port: 8000
resources:
memory: 512m # Unit suffix REQUIRED — k, m or g
health_check:
path: /health
interval: 15 # Seconds between checks (default 30, range 5-300)
timeout: 10 # Seconds to wait for a response (default 5, range 2-120)
healthy_threshold: 2 # Successes to mark healthy (default 2, MINIMUM 2)
unhealthy_threshold: 5 # Failures to mark unhealthy (default 3, minimum 2)
startup_timeout: 300 # Max seconds to become healthy on deploy (default 120, range 30-600)
resources.memory needs a unit suffix
Write 512m, 1g or 262144k. A bare number is interpreted as bytes, so resources: {memory: 512} gives the container 512 bytes and it will be killed instantly. 512mb is not a recognised suffix either — use 512m.
Containers that exceed their memory limit are killed. Size conservatively and monitor with mecca app stats.
resources.cpu is accepted but does nothing
The schema will parse 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 resource AppMecca actually enforces.
healthy_threshold and unhealthy_threshold have a minimum of 2
Setting either to 1 is rejected at validation time. The valid range for both is 2-10.
Slow-starting services
If your service takes a long time to start (loading ML models, warming caches, running migrations), raise startup_timeout — that is the budget AppMecca gives a brand-new container to pass its health check during a deploy. Raising interval and unhealthy_threshold widens the tolerance once it is running.
JVM and SPA memory floors
A command: that looks JVM-shaped (java …, *.jar, gradle) with memory below 512m produces a warning at validation time — JVM runtimes routinely get killed during startup at the platform's 128 MB default. A type: spa service with memory below 32m is a hard error, because below that the nginx worker gets killed silently while the master survives.
There is no auto-rollback
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 router 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.
Step 2: Pre-release backup workflow¶
Before deploying a release with schema changes, create a named backup:
Deploy the new version:
If something goes wrong, roll the container back to the previous image, then restore the database from a pre-release bundle:
# Roll the containers back to a known-good image (a deploy with --no-build)
mecca build list -a todo-app -e dev
mecca app deploy todo-app --image-tag abc122e --no-build -e dev
# Restore the pre-release database bundle (separate, destructive step)
mecca app backups todo-app -e dev
mecca app restore todo-app <bundle-prefix> -e dev
Rollback + restore are two steps
There is no combined rollback-plus-restore command. Roll the
container back with mecca app deploy --image-tag … --no-build, then
restore the database with mecca app restore if a migration must be
reverted. See Rolling Back.
Step 3: Deploy a specific version¶
List available builds and deploy a specific tag — this is also how you roll back (target an older tag):
mecca build list -a todo-app -e dev # Tag + Status, newest first
mecca app show todo-app -e dev # what is LIVE right now
mecca app deploy todo-app --image-tag abc123f --no-build -e dev # deploy an existing image
mecca app deploy todo-app --image-tag abc123f --no-build -e dev
--no-build re-uses an image that already exists, so a rollback cannot be blocked by whatever broke the build — and it is fast.
Step 4: Check what is running¶
mecca app show todo-app -e dev # per-service status and URLs
mecca app stats todo-app -e dev # live memory and CPU per container
mecca app stats todo-app --history -e dev # daily aggregates
mecca status todo-app # service health and uptime
For deployment troubleshooting, mecca debug gathers everything in one shot — configured variables, recent deploy errors, per-service health and resolved URLs:
Step 5: Production appmecca.yaml¶
Here is the complete production-ready configuration combining all patterns from this tutorial series:
database:
enabled: true
redis:
enabled: true
containers:
- name: backend
dockerfile: backend/Dockerfile
context: backend/
- name: frontend
dockerfile: frontend/Dockerfile
context: frontend/
deploy:
- name: backend
container: backend
port: 8000
path: /api
replicas: 2 # 1-3; each replica lands on a different host
resources:
memory: 512m
health_check:
path: /health
interval: 15
timeout: 10
healthy_threshold: 2
unhealthy_threshold: 5
startup_timeout: 300
environment:
CELERY_BROKER_URL: "${redis_url}"
- name: frontend
container: frontend
type: spa
command: 'nginx -g "daemon off;"' # serves the built bundle from a container
spa_root: /usr/share/nginx/html
port: 3000
resources:
memory: 128m # never below 32m for type: spa
health_check:
path: /
environment:
PUBLIC_API_URL: "${service:backend}"
PUBLIC_APP_TITLE: "Todo App"
- name: worker
container: backend
command: "celery -A config worker --loglevel=info --concurrency=2"
resources:
memory: 256m
environment:
CELERY_BROKER_URL: "${redis_url}"
replicas is capped at 3
Valid values are 1-3. Each replica is placed on a different host for redundancy, so asking for more replicas than there are eligible hosts is refused rather than silently doubling up. Remember that database.max_connections is counted per replica.
Step 6: Full application cleanup¶
When you are done with the tutorial and want to remove everything:
# Stop all running services (registry data preserved)
mecca app undeploy todo-app --force -e dev
# Full purge — everything the app owns
mecca app delete todo-app --force -e dev
app delete is permanent
mecca app delete --force removes all traces of the application: it backs up and then drops the database, deletes the built images from AppMecca's image registry, removes the app's build configuration, stored secrets and collected logs, and clears every registry row. There is no undo.
mecca app unregister is the same command under a different name — it is not a lighter-weight option.
Tutorial complete¶
You have deployed a Django + React application on AppMecca, progressing from a hello-world endpoint to a production-hardened multi-service deployment. Here is a summary of what each part covered:
| Part | Topic | Key concepts |
|---|---|---|
| 1 | First Deployment | CLI setup, register, build, deploy, undeploy |
| 2 | Adding a Database | Managed PostgreSQL, migrations, backups, restore |
| 3 | Going Full-Stack | Multi-container builds, ${service:backend} |
| 4 | SPA Runtime Config | type: spa, window.__APPMECCA_CONFIG__, PUBLIC_* |
| 5 | Background Workers | Celery, portless services, command override |
| 6 | Branch Deployments | Feature branches, side-by-side testing, promotion |
| 7 | Internal Service Discovery | ${service:name} vs ${service:name:internal}, visibility |
| 8 | Production Patterns | Memory limits, health tuning, rollback |