Projects

Forte organizes resources into Projects. A Project isolates your Users, Services, Websites, Databases, Payments, and Content.

Resources can work together only within the same Project. For example, a User can call any Service in that Project.

Projects are free, with no limit on how many you create. To run staging next to production, clone an environment from an existing project.

Sandbox (test) mode

When you create a Project, you can choose to enable sandbox mode. Sandbox projects are ideal for test and pre-production environments. Enabling sandbox mode gives you access to destructive user administration and contact method overrides, and routes Payments through Stripe Test mode.

Sandbox projects are ideal for:

• Development and testing environments: Reproduce edge cases, reset state freely, and test payment and auth flows without real card numbers or waiting on real codes.
• End-to-end and integration testing: Run automated test suites against a real API without touching production data or spending real money.

What's different in a sandbox project

• Hard-delete users: In a live project, users can only be suspended (deactivated with their record retained). In a sandbox project, deletion is immediate and permanent, so you can reset state between test runs. See Administration.
• Override contact methods and verification: You can change a contact method's value or mark it verified without sending a real code. Useful for seeding test users and reproducing edge cases. See Contact Methods.
• Fixed test verification codes: Assign a fixed one-time code to a designated test contact method; every OTP that would be sent to it (verification, one-time-code sign-in, email/SMS MFA) uses that code and nothing is delivered. See Contact Methods → Fixed Test Codes.
• Email before compliance approval: Choose the Forte sandbox email sender to turn on email and password sign-in and send templated email before your compliance registration is approved. Mail is marked [Sandbox] and limited to 5 emails per day, and template emails go only to addresses verified with a code or Google sign-in. See Email Templates → Sandbox email sender.
• Request/response body logging on by default: Sandbox projects capture full request and response bodies by default; live projects leave this off to avoid logging sensitive production data. Toggle it per service at any time. See Monitoring.
• Test payments: Payments route through a fully sandboxed environment; no real money moves. Use Stripe's test cards to simulate charges, declines, and 3D Secure.

When not to use sandbox mode

Live and sandbox data is isolated. Do not use a sandbox project for:

• Production user traffic: Real users should always authenticate against a live project.
• Real billing: Payment methods and charges in sandbox are test-only.
• Real compliance data: KYC and other compliance information in a sandbox is not treated as legally binding.
• Personal information about real customers: Sandbox projects offer fewer safeguards (hard-delete, direct overrides), so they are not appropriate for real customer PII.

Live versus sandbox summary

Creating a project

Environments

Clone a project to get a second copy of it, such as staging next to production. Open the project overview, click Clone environment, and enter a name. The clone appears in the project picker under the project it came from, and the overview shows its setup progress while databases, services, and websites come up.

Copied:

• Services, websites, and databases, with the connections between them
• Environment variables and secrets
• Actions and payment triggers
• Sign-in settings and email templates

Not copied:

• Custom domains
• Database data (copied databases start empty)
• Database users
• End users
• API keys

Copies keep their GitHub branches, so a push deploys to both environments until you set a different branch on each copied service and website. A clone keeps the source project's sandbox or live mode, and that can't be changed later. Cloning a live project gives you a live environment whose payment triggers take real payments.

The environment has new domains, so add them to the allowed origins of your Google sign-in client and reCAPTCHA key, and update any copied environment variables that hold the source project's URLs, since those aren't rewritten.

Each environment is billed separately and counts toward your account limits. You can't delete a project until you delete its environments.

What's in a project?

Each Project contains:

• Users: Your customers who can authenticate and interact with your Services
• Services: Containerized applications that run your code on Forte's autoscaling infrastructure with built-in authentication
• Websites: Front-end applications built from your repository and served over a global CDN
• Databases: Managed PostgreSQL and MongoDB-compatible databases (Open Beta)
• Payments: Charge your users with tax calculation and recurring billing
• Content: Private storage with moderation and a CDN for images and video

Best practices

Keep test and production in separate projects. An environment keeps the sandbox or live mode of the project you clone it from, so cloning a live production gives you a live staging. For a sandbox staging, start from a sandbox project and clone that. If you need shared test accounts (for example, a fixed login for Apple or Google app-store review), use contact method overrides and fixed test OTP codes in your sandbox project.

Next steps

• Create your first service within a project
• Learn about users and how authentication works