Build a custom app
Build your own product on a copy of the Arc CMS repository. Sign-in, users, email, an admin area and more are there on day one, and your code lives in a separate custom space so Arc CMS updates merge cleanly.
Is this the right choice
| You want | Do this |
|---|---|
| A new product with members, its own data and pages, and an admin area, on Firebase | Build on a copy of Arc CMS (this path) |
| A content website, with no code of your own beyond templates | Build a website |
| Arc CMS next to an app you already have in its own Firebase project | Share a Firebase project, then Connect your app's users |
| To change how an Arc CMS feature itself works | Build it in Arc CMS as a general feature, then pull it (Keep core generic) |
See A website or an app for a longer comparison.
What you get without writing code
| Area | What is there | Read |
|---|---|---|
| Sign-in | Email, Google and phone sign-in, sign-up, and the first-admin setup | Sign-in methods |
| Users and roles | User records, roles, custom claims, account deletion | Users and roles |
| A provider setup, brand kit, composer, transactional emails, logs and unsubscribe | Email engine | |
| Audience | Contacts, lists, tags, broadcasts and drip sequences | Audience |
| Payments | Products, checkout, transactions and premium entitlements | Payments |
| Installable app | Manifest, icons, service worker and install prompt | Installable app (PWA) |
| Content | Content types, templates, media, search and SEO | Content |
| Everyday tools | Feedback button, notifications, banners, analytics, data import and export | All features |
You turn off what your app does not need in one file (Choose your app's features).
The one rule: never edit core
Every file Arc CMS ships is core. Your app's code goes only in the custom space: src/custom/, functions/src/custom/, your own rules and index files, custom/ at the root for scripts and data, and your CI workflows in .github/ (Use the custom space). Arc CMS ships those files once, empty, and never changes them again, so pulling an update never conflicts with your work.
If your app needs something core does not offer, it becomes a general feature or a new plug point in Arc CMS, and your app pulls it. Before every commit, run:
npm run check:core
It lists every core file you changed and fails when there is one. See Core and custom for the reasoning.
The steps, in order
Start with a working copy: Install, Configure a project and Create the first admin. Then:
Use the custom space: learn which file does what.
Choose your app's features: turn off what the app does not need.
Add pages and routes: the app's own screens.
Change the admin menu: links to your admin screens, and changes to Arc CMS's items.
Build the member area: where signed-in people land and what they see.
Write your own Cloud Functions: callables and triggers.
Set security rules and indexes: protect the app's data.
Follow the account contract: where each person's data lives.
Set up sign-in: choose how people sign in.
Add payments and premium features: charge for the app.
Make it installable: name, colors and icon.
Connect your app's users: email the app's users from Arc CMS.
Share a Firebase project: only when Arc CMS lives next to another app.
Keep core untouched: check your work and pull Arc CMS updates.