Skip to content

Step 17 — Teams, cost, and cleaning up

About 25 minutes. Branch: step-17. No code changes.

The one new idea: a group is the unit of ownership — and it has been in front of you since step 1.

The last label of every URL

mecca group show
mecca group list

Apps belong to a group, not to you. Membership of a group is what gets you past the login page on its private apps. Cost rolls up to it. Its slug is the last label of every URL you have opened in this tutorial.

That is why it is the unit worth understanding before you invite anyone: adding someone to a group is not a per-app decision.

mecca group create acme
mecca group invite acme --email colleague@example.com
mecca group members acme
mecca group role acme colleague@example.com --role administrator
mecca group remove acme colleague@example.com

Once you belong to more than one, --group picks which you mean, and mecca use <slug> sets it for the session so you can stop typing it.

What it costs

mecca usage summary tally
mecca usage report

Worth looking at now, while the tutorial's apps are still running, because the numbers attach to something you recognise: a container you sized at step 6, a database you declared at step 7, a drive you sized at step 11.

report covers everything you can see, which is the group-level view.

Take it down

mecca app delete tally -b tutorial

This is a full purge: containers, database, drives, buckets, routing, history. It is not reversible and it does not tip-toe.

If you created a second branch at step 12, it is a second app

It needs deleting separately:

mecca app list
mecca app delete tally -b experiment

That is the last time this tutorial makes the point, and it is the same one it opened with.

Backups outlive the app. Deleting does not delete bundles. If you want them gone, mecca app backup-delete each one before you delete the app — after that they are still there and harder to find.

mecca app list      # confirm nothing is left running

You are done

You can deploy a static site, containerise it, give it a database, a cache, a worker, scheduled work, email and storage; read the queue and three kinds of log; recognise a silently-ignored key; run two branches; back up, restore and roll back; split a frontend onto its own path; configure an edge cache; and hand the whole thing to a colleague.

Where to go next

  • The guided demos take single features further than a tutorial step can — storage, databases, background work, the runtime, service wiring, and a whole demo about reading the evidence when something breaks.
  • The reference documentation is organised by subsystem. Every step here named the keys it used; that is where the rest of them are.
  • When it breaks — the symptom-to-command index from all seventeen steps, on one page. Worth a bookmark.
  • This repository is MIT licensed. Strip Tally out and keep the shape. A frontend, an API, a worker, a database, a cache and somewhere to put files is a reasonable skeleton for a great many things — and it already deploys.