Hosting and Deployment Models
The platform is not tied to one hosting shape. The same application runs on a single modest server or across a sharded multi-tenant estate, and the difference is configuration rather than code.
Where to find it
Architect Panel → Configuration:
- Site Settings — deployment target and tenant database mode
- Multitenancy — tenant configuration and isolation
Architect Panel → Integration & Connections:
- Database Hosts — the servers tenant databases are distributed across
- Deployments — pushing a version out
Single server
One PHP-capable web server and one MySQL or MariaDB database. Right for internal tools, small products and every development environment.
Do not over-engineer past this before you need to. A single well-specified server carries a surprising amount of load, and the operational simplicity is worth real money.
Multi-tenant, shared database
Every tenant's rows live in one database, separated by a tenant identifier carried on every row. Cheap to run, simple to back up, and the default.
The isolation is enforced in the platform rather than by the database, which is why the tenant column is present everywhere and why you should never bypass the platform's query layer in custom code.
Multi-tenant, separate databases
Each tenant gets its own database, with connections managed for you. Choose this where isolation is a requirement rather than a preference — a regulator asking how one client's data is separated from another's is much more easily answered by "different database" than by "a column".
It also makes per-tenant restore possible, which is the operational argument. Restoring one tenant from a shared database is an extraction exercise; from a separate database it is a restore.
Sharding
When one database server is not enough, tenant databases are distributed across several Database Hosts. Sharding works with either isolation mode.
This is a scaling answer, not a starting position. Introduce it when a single host is genuinely the constraint, and not in anticipation.
The five deployment engines
- AWS Beanstalk — for autoscaling production estates.
- SFTP and FTP/FTPS — for conventional hosting.
- Network Drive and Local Folder — for on-premises and development.
Deployment pushes a version of the application out through the chosen engine. Database changes are a separate, deliberate exercise — they are not applied automatically as part of a deployment, and they are not gated by an automated test run. Plan schema work as its own step with its own rollback.
Choose isolation before go-live
Moving from shared to separate databases after tenants are live is a migration, not a setting change. Decide at the start, and lean towards separate if there is any prospect of a client asking the isolation question.
Worked example
A product launches on a single server with shared tenancy. At around forty tenants, two enterprise customers ask for their data to be separately held, so those two are moved to separate databases while the rest stay shared. A year later a second database host is added and the largest tenants are distributed across both. Nothing about the application changed at any point.
Recommendations
- Start on a single server.
- Decide the isolation mode before tenants exist.
- Shard when a host is the constraint, not before.
- Treat schema changes as their own deployment step with a rollback.