Deployment topology
SupaCloud runs in two shapes, and the difference decides where content is seeded, which automation is legitimate, and what a feature is allowed to assume.
The two shapes
Section titled “The two shapes”Hosted SaaS. The vendor operates one multi-tenant instance for customers. This is the home of the official marketplace catalog: the curated items are seeded there so buyers find them. Its content lives in a repository separate from this one, because this repository is open-source-bound and must build with no vendor content inside it.
Self-hosted. An operator runs SupaCloud on their own infrastructure — one organisation, their own database, their own credentials. The vendor’s own staging deployment is also self-hosted: it is the same shape a customer deploys, which is why it doubles as the proving ground for the self-hosted path. It is additionally the vendor’s own workbench, so the workspaces on it are in-house work, not product content.
The rule: the product path stands alone
Section titled “The rule: the product path stands alone”A fresh instance must reach every capability through SupaCloud’s own surfaces — web UI, API, marketplace, CLI. No vendor infrastructure, no vendor configuration-management, no vendor secret store, no accounts that only exist inside the vendor’s fleet.
This is not a preference. An instance that needs the vendor’s Ansible to become usable is not self-hostable, and a capability whose only route runs through the vendor’s secret store cannot ship to anyone else.
Two consequences follow, and both are load-bearing:
Ops automation may use the product paths, never replace them. Provisioning a deployment from configuration management is welcome — the vendor does exactly that for its own staging instance — but it must drive the same Management API, marketplace seed and resource endpoints an operator would use by hand. When the automation needs a route the product does not have, that is a missing feature, not a reason to write directly into the database.
A configuration value you can only know from the inside is a product defect in disguise. If a field expects a library path, a host name or an account convention that a stranger has no way to discover, the gap is not documentation — it is a missing selection. The fix is to let the product list what it can reach and have the operator choose, not to write the value down somewhere.
Where content lives
Section titled “Where content lives”| Repository | Contents | Seeded to |
|---|---|---|
| this repository | the content-agnostic mechanism (seeder, connectors, workflow engine) | — |
| marketplace catalog | curated official items (connectors, workflow templates) | hosted SaaS |
| per-workspace content | one operator’s own workflows, apps and rules | that operator’s own instance |
The seeder takes a catalogue directory and publishes what it finds; it holds no knowledge of any particular item. That split is what lets the product ship without the vendor’s catalogue and lets the catalogue change without a release.
How this shows up in review
Section titled “How this shows up in review”When a change is proposed, the question is not only “does it work here” but “how does a stranger on a bare instance reach this?” If the honest answer involves the vendor’s fleet, the change is not finished — the ops shortcut may exist, but it may not be the only door.