At this point, the system is online. Now you need to make it usable.

0. Keep the Dev Console open during this step

This is a good phase to keep the Dev Console available for reference.

It helps when you need to double-check:

• app keys
• service values
• environment files
• startup status

1. Log in to the admin first

Your first real operational step is logging into the admin interface.

If you forgot what values you entered

Check the environment variables and auth-related config first before assuming the system is broken.

Most "I cannot log in" problems at this stage are configuration mismatches, not deep code bugs.

If login keeps returning 401

Treat that as a configuration problem first.

Check:

• auth service secrets
• frontend auth endpoint configuration
• production domain settings
• whether the frontend is still pointing at old or local addresses

Operators & RBAC (optional)

After the console works with ADMIN_SECRET, you can create operator accounts (email + password) with scoped permissions instead of sharing the root secret—for example read-only access to dashboards and logs for operational visibility without broad edit/delete rights (revoke or deactivate the account when access should end). See Admin RBAC & operator accounts, section Use case: let people observe operations without mutating data.

2. Create a demo project first

For the first pass, create one project with the default key.

Recommended first values

Start with something simple and predictable:

• use demo as the first app_key
• fill the minimum required project fields
• avoid customizing too many product-specific settings until the base flow works

This is the fastest path to a fully verified system.

3. If you need payments, continue with payment channels

After the basic project exists, configure payment channels if your product needs them.

That typically includes:

• enabling providers
• filling product or price data
• confirming callback and webhook behavior

4. If you need AI, continue with model setup

If your product depends on AI features, this is the right time to configure:

• model providers
• API keys
• gateway settings
• model mappings

5. If you want the site to feel like a real product, fill these sections

Do not stop at infrastructure.

Use the admin to fill the parts that make the product look complete:

• site branding
• visible product copy
• pricing content
• support and contact information
• blog or content settings if needed

6. Check auxiliary modules such as check-in, support, and notifications

After core setup, verify the helper modules too.

These modules are easy to ignore during first deploys, but they matter for real use:

• check-in
• support
• notifications

7. If you are ready to switch to your own app_key

Once the system is stable with demo, you can move to your real production app_key.

Do it carefully:

1. create or update the project in admin
2. switch the frontend environment variables
3. redeploy the frontend
4. verify the site is now reading the intended project data

8. Checklist before you leave this chapter

Before calling the initialization complete, confirm:

• you can log into the admin
• a demo project has been created successfully
• payments are configured if needed
• AI is configured if needed
• site branding and core content are filled
• support, notifications, and other helper modules are behaving normally
• the real app_key migration plan is clear if you intend to switch away from demo

9. Cross-check with launch troubleshooting

After initialization, walk through Launch Checks §1 again (public site, admin, signup/login, optional modules). If the admin Health page shows a service in a bad state, follow its hints and use §2 Observability on the matching Worker.

Multiple environments: these docs assume one primary production stack. If you add staging or preview, use separate app_key values, Workers/Pages projects, or env vars so webhooks and domains are not shared with production by mistake.