Platform
Isolation & networking
foro.sh runs code you didn't write, from repos you don't control. Isolating that from other projects, from the platform itself, and from the host it runs on is the default for every deployment. It isn't something you configure or pay more for. Here's what that isolation is made of.
One container per project
Every deployed server gets its own container - never shared with another project, never reused across a redeploy. A redeploy builds a fresh image and starts a fresh container under the same URL; nothing from a previous version carries over except what you explicitly configured (secrets, the manifest).
One private network per project
Each project's container sits on a network reachable by nothing except the platform's own routing layer - not other projects' containers, and not the platform's internal services (database, job queue, internal API). A server can be as loud as it wants on its own network; there's nothing there to reach.
No standing privileges
A deployed server's process runs as an unprivileged user, can never regain privileges it starts without, and can't write to its own filesystem outside a small scratch area. It gets exactly the compute it's allocated - no more CPU, memory, or process count than its plan grants, with no backdoor toward the host's own resources.
Restricted outbound access
Outbound connections from a deployed server are allowed to the open internet, so a project can call whatever APIs it needs - but not to the platform's own private infrastructure or other internal-only ranges, so a compromised or malicious project can't use its egress to reach anything it isn't meant to.
A separate, sandboxed build step
Installing your project's dependencies runs before your code ever executes as a live server, and it runs in its own capped, isolated environment - separate from the one that serves traffic. A build doing something unexpected can't affect a running server, yours or anyone else's.
Can one deployed server reach another?
No. Each project's container sits on its own private network, reachable by nothing except the platform's routing layer - not other projects' containers, and not the platform's own database, job queue or internal API. There is no route between two projects.
What can a deployed server reach on the internet?
Outbound connections to the open internet are allowed, so a project can call whatever APIs it needs. Connections to the platform's own private infrastructure and other internal-only ranges are not, so a compromised project cannot use its egress to reach anything it is not meant to.
Does a redeploy reuse the old container?
No. A redeploy builds a fresh image and starts a fresh container under the same URL. Nothing from the previous version carries over except what you configured explicitly - your secrets and your manifest. Containers are never shared between projects either.
This is the isolation model in depth. For a shorter, evidence-linked summary of this control alongside the platform's other guarantees, see security specifications.
These layers are defence in depth, not one single perfect barrier. If you find a gap in one, please report it privately to [email protected] rather than opening a public issue. We acknowledge within 3 business days.