Getting started
EasySiteControl is a workspace for running the backend of your websites: content, APIs, automations, media and sign-ins. The defining idea is ownership — every record lives in a MongoDB you supply, not in ours. This guide takes you from nothing to a working project.
1. Create a workspace
Sign up at the home page with a subdomain, an organisation name and your account details. The subdomain becomes your team's permanent address:
https://<your-subdomain>.easysitecontrol.com
Everyone on your team signs in there. Common names (app, admin, dev, api and similar) are reserved.
2. Create a project
A project is one website or application: its schemas, records, media, forms, endpoints and users all live together. From the dashboard, create a project — it starts in a pending database state, because a project cannot hold content until it has somewhere to put it.
3. Attach your database
Open the project and attach a MongoDB connection string:
mongodb+srv://user:password@cluster.example.mongodb.net/my-site
- Atlas, self-hosted, any provider — anywhere the platform can reach over the public internet. Private and internal addresses are rejected by design (a connection string is also a network destination, and yours should not be able to point at someone else's infrastructure).
- The credential is encrypted at rest with the platform's key ring and is never returned by any API once saved.
- Everything the project stores — records, form submissions, media metadata, end users, automation logs — goes into this database. Leaving the platform is pointing your apps at it directly.
The project activates the moment the connection verifies.
4. Model something
Head to Schemas and define your first content type — see the Schemas & records guide. From there:
| You want | Go to |
|---|---|
| Content types and a records API | Schemas & records |
| Your own API routes, no server code | Endpoints |
| Automations on form/record activity | Events |
| Sign-in for your site's visitors | Auth schemas |
| A contact form that just works | Forms |
| Images and files | Media |
| Teammates, roles, API keys | Members, roles & API keys |
| SMTP, S3, Redis, database settings | Integrations & settings |
Where things run
- The dashboard (
your-subdomain.…/dashboard) is where your team works. - The APIs live under
…/api/projects/<project-id>/…— generated records APIs, your custom endpoints, and the public auth routes your site calls. - Project members are dashboard users you invite with a role; end users (via auth schemas) are your site's own customers. The two never mix.
The safety model, in one paragraph
Every request is scoped by the subdomain it arrives on — a project ID from another workspace simply does not resolve. Inside a workspace, every project-scoped action passes one gate that checks the project belongs to the workspace, the caller may access it, and their role or API key grants the specific permission. Outbound calls the platform makes on your behalf (webhooks, SMTP, S3) are validated against private-network access at the moment of use.