The config wizard¶
Answer a handful of questions and AppMecca writes your appmecca.yaml for you.
Open it from the dashboard at your group → Apps → “No appmecca.yaml yet? Build one”,
or go straight to /g/{your-group}/config-wizard.
You end up with a file to download and commit to the root of your repository. Nothing is changed on the platform — the wizard only writes a file.
What it asks¶
It starts with the one question that shapes everything else — what are you deploying? — and only asks follow-ups that your answers make relevant. A single-page site takes about six steps; a frontend, an API and a worker with a database, a drive and a scheduled job take twelve or thirteen.
The progress header reads “Step 3 of ~9”. The ~ is deliberate: an answer further in
can genuinely add or remove a step, and a confident “of 9” that becomes “of 10” reads
as a bug rather than as the wizard adapting.
“Who calls this part?”¶
Every part you name answers this, and it is the question the rest of the routing follows from:
| Answer | What it means |
|---|---|
| Browsers / the public | People reach it. It gets a URL and a health check. |
| Only my other parts | A backend your own services call. Reachable at ${service:name:internal}. |
| Nothing — background work | A worker or scheduler. No port, no URL, and that is normal. |
You never have to think about mount paths or hostnames; the wizard works out what your environment needs from that answer.
What it checks before you download¶
The file is validated by the same validator the platform runs on every deploy — not a copy of it. So a config the wizard says is clean is clean, and a problem shows up here rather than after a build.
You will see two kinds of message:
- Errors — the config will not deploy yet. These are yours to fix, and the wizard says which field.
- Worth knowing — advisory. A JVM-shaped command with a small memory limit, for instance, which is technically valid and reliably fails at startup.
If you ever see “the wizard produced a setting this platform does not recognise”, that is a bug in the wizard rather than anything you did — please report it.
What it chose for you¶
The review step lists every default the wizard applied and every setting it deliberately did not ask about, with where to change each one. Nothing is hidden: if a field is not in your file, the review step tells you what value the platform will use instead.
Settings like per-path cache rules and edge redirects are left out on purpose — they are worth tuning once your app is serving, and they are not worth a question before it has deployed once.
After you download it¶
- Save the file as
appmecca.yamlat the root of your repository. - Commit and push it.
- Register the app (
mecca register <git-url>), or press Re-check if you already did.
Things the wizard cannot check from here
A few rules depend on live platform state rather than on your file:
- Drive storage above the free allowance needs an operator grant. The wizard warns but cannot confirm it for you.
- Database connection budgets are checked against the whole fleet at deploy time.
- Whether your Dockerfile exists is checked when the platform clones your repo.
None of these block the file being correct; they are checked when you deploy.