Architecture overview
How it works
- Your users access the Forest UI hosted at
app.forestadmin.com - Forest UI makes API calls to your back-end
- Your back-end runs in your infrastructure (AWS, GCP, Heroku, etc.)
- Your back-end queries your database directly
- All data stays within your infrastructure
Key benefit: This architecture follows our privacy by design motto. Your data never leaves your infrastructure.
Components
| Component | Hosted by | Location | Responsibilities |
|---|---|---|---|
| Your Back-end | You | Your infrastructure | • Runs in Node.js or Ruby • Direct access to your database • Executes business logic (actions, computed fields, hooks) • Handles authentication and authorization • Exposes REST API for Forest UI |
| Forest UI | Forest | app.forestadmin.com | • Back-office interface for your users • Communicates with your back-end via HTTPS • Receives only schema metadata (no data) • Managed and updated by Forest |
| Your Database | You | Your infrastructure | • PostgreSQL, MySQL, MongoDB, etc. • Only accessible to your back-end • No direct connection from Forest • Your data never leaves your infrastructure |
Back-end deployment
You can deploy the Forest back-end in two ways, depending on your application architecture:In-app deployment
With in-app deployment, the Forest back-end becomes part of your existing application. It runs in the same Node.js or Ruby process, sharing the same database connection pool and resources. When you deploy your application, the back-end deploys with it as a single unit. This approach is particularly valuable when you want to leverage your existing ORM models. Whether you’re using Sequelize, Mongoose, or ActiveRecord, Forest can read directly from your model definitions, no need to redefine your schema. You can also reuse your existing business logic, sharing code, services, and utilities between your application and Forest without duplication.
Standalone deployment
Standalone deployment runs the Forest back-end as a completely separate service. It operates in its own process or container with dedicated resources and its own database connection pool. Your application and the back-office are deployed and scaled independently. This architecture provides a cleaner separation of concerns. Your application code stays focused on your business logic, while Forest responsibilities are isolated in their own service. The two services communicate through well-defined boundaries, making your overall system architecture simpler to understand and maintain. This is particularly beneficial as your team grows, developers working on the application don’t need to think about back-office concerns, and vice versa.Note: Standalone deployment is currently available for Node.js only. If you need standalone deployment with Ruby, please contact our sales team.
Recommendation: We recommend standalone deployment for cleaner architecture and better separation of concerns. Use in-app if you need to reuse your ORM models or existing business logic.
Privacy by design
The self-hosted architecture is built with privacy as a core principle. Here’s how data flows when a user accesses Forest:
app.forestadmin.com, api.forestadmin.com) only send configuration and UI code to your browser. All data requests go directly from your browser to your back-end behind your firewall, and your data never leaves your infrastructure.
Looking for a different setup? Forest also offers on-premise deployments where even the Forest UI runs in your own infrastructure. Contact us to find the right fit for your organization.