Your AI writes it.
AppMecca runs it.
Deployment is the step AI assistants are worst at — not because it's hard, but because they're guessing. We wrote down the answers.
One file. Any assistant.
Your coding agent has never seen our platform. Left to guess, it invents a config format, hallucinates CLI flags, and burns your afternoon on a build that was never going to work. So we wrote a single, self-contained file that tells it exactly how AppMecca works — and we keep it verified against the platform's own validation code, not against someone's memory of it.
Drop it in your repo once. Every deploy after that is a sentence.
# Wherever your assistant reads instructions from:
your-project/
APPMECCA.md ← the guide
CLAUDE.md or append it to this
AGENTS.md or this
.cursorrules or this
appmecca.yaml ← your agent writes this
Dockerfile ← and this
# That's the whole integration.From vibe code to production
Add the guide to your repo
Save it as APPMECCA.md, or append it to whichever instruction file your assistant already reads — CLAUDE.md, AGENTS.md, .cursorrules, GEMINI.md.
Build your app as normal
Your agent writes the application. Nothing about AppMecca changes how you code, and nothing is locked to us.
Ask it to deploy
The guide tells your agent what to inspect, what to ask you, and what to write. It produces the appmecca.yaml and the Dockerfile, then runs the CLI.
It reads the result back
Deploy status, build logs, container logs and health checks all come back through the same CLI — so your agent can tell whether it actually worked, and fix it if not.
Roughly 1,800 lines of hard-won specifics
Not a marketing overview — a reference an agent can act on without reading our source code.
Pick the right shape first
A decision tree that classifies your project — container app, static site, SPA, or a mix — before a single line of config gets written. Most wasted deploys start with the wrong answer here.
The complete config reference
Every key in appmecca.yaml, what it does, what it defaults to, and what it refuses. Services, ports, health checks, replicas, memory, cron, visibility, edge caching.
The Dockerfile contract
What your image must do to be deployable here — how the port is bound, what the health check expects, how migrations should run, and why running as root will bite you.
Backing services in one line each
Postgres, Redis, shared file storage, object storage and transactional email — what to declare, and exactly which environment variables show up inside the container as a result.
The traps, called out as traps
The cases where the platform accepts your config silently and then behaves in a way you didn't expect. These are the ones that cost hours, so they're flagged inline rather than buried.
A step-by-step operating procedure
The final chapter is an ordered runbook: what to inspect, what to ask you and when, and how to verify each step landed before moving to the next. Written for the agent, not for you.
Everything you can do, your agent can do
There is no reduced agent API. Your assistant drives the same CLI and the same REST API you use — so anything in the docs is available to it, and nothing it does is invisible to you.
Deploy and roll back
Register a repo, build, deploy, redeploy a branch, or put an earlier image back — all from the terminal it already has.
Read what happened
Build logs, container logs, deploy phases, health status and a one-shot diagnostic dump — so it can debug its own deploy instead of asking you to paste an error.
Manage the app
Environment variables, custom domains, scheduled jobs, storage, backups and restores. Plus one-off commands inside a running container for migrations and shell tasks.
No integration to install
The guide is a markdown file and the interface is a CLI. If your assistant can read your repository and run a command, it can deploy to AppMecca — today, with no plugin and no waiting for us to support it.
Claude Code & Claude Desktop
Append the guide to CLAUDE.md. Claude picks it up automatically on every session in that project.
Cursor, Windsurf & Copilot
Add it to .cursorrules or .github/copilot-instructions.md — whichever your editor already loads as project context.
Anything else
Gemini, a home-grown agent, a CI script. The guide assumes nothing about which model is reading it, and the CLI speaks --json on every read command.
A real deployment conversation
You: Build me a recipe sharing app with user accounts,
a PostgreSQL database, and a React frontend.
Agent: I'll build that for you. Let me create the project
structure...
[builds the app over several messages]
The app is ready. Want me to deploy it to AppMecca?
You: Yes, deploy it.
Agent: Reading APPMECCA.md. This is a mixed-shape app —
a Django API in a container and a React frontend
that builds to static files. Two services.
Before I register it: which branch should be
production, and do you want it public or
members-only?
You: main, and public.
Agent: ✓ Wrote appmecca.yaml (api + web)
✓ Wrote Dockerfile, non-root, migrations on boot
✓ mecca register — pre-flight passed
✓ mecca app deploy recipe-share
✓ Database provisioned, DATABASE_URL injected
✓ Health checks passing on both services
Live at recipe-share-web-yourteam.us.appmecca.net
Want me to add a custom domain?