Cloud, Private Cloud and On-Premises
By the Syncfusion DevTutorials team · Last updated
Run the same product in your cloud, in a customer's cloud account and in an air-gapped data centre from one build: interfaces and adapters, config profiles, offline licences and signed release bundles.
"Can We Run It Ourselves?"
Globex (tenant t43) is a manufacturer with strict security rules. Its sales team loves Northwind, but its IT team has one condition: it runs in Globex's own data centre, with no connection to the internet. A bank wants it in its own cloud account. Everyone else is happy in Northwind's cloud.
Many B2B vendors face this. Syncfusion's Bold BI and Bold Reports, for example, are offered both as cloud services and as software customers host themselves. The trap is to say yes by copying the code: a "cloud edition" and an "on-premises edition" that drift further apart with every release, until each fix has to be made twice.
The main idea: ship one build. Hide every external service behind an interface with an adapter per environment, choose the adapters and features with a config profile, make telemetry, licensing and updates work offline, and run the same tests in every profile before release.
TL;DR
- One build, one version line. Differences live in config profiles and feature flags, not in forks or
if (onPrem)code. - Put each cloud service behind an interface you own, with adapters: SQS or RabbitMQ, S3 or MinIO, SES or SMTP.
- Prefer open protocols: plain Postgres, the S3 API, SMTP, OpenID Connect.
- Offline-friendly operations: telemetry the customer can redirect or turn off, a signed licence file, and signed release bundles the customer installs.
- Run the same test suite in every profile for every release.
A Real-World Example
A software company kept its on-premises edition on a separate branch "for now". Three years later the branch was 4,000 commits behind, security fixes took a month to port, and on-premises customers were two major versions behind the cloud. Merging it back took a team most of a year: the cost of one shortcut.
What You Will Learn
- What changes between cloud, private cloud and on-premises.
- How interfaces and adapters keep one codebase.
- How config profiles replace code branches.
- How licences, updates and telemetry work without internet.
Three Ways to Run the Same Product
One signed build. Interfaces hide each external service; a profile picks the adapters and settings for each place it runs.
| Cloud | Private cloud | On-premises | |
|---|---|---|---|
| Who runs it | Northwind | Northwind's build, customer's account | The customer |
| Internet | Yes | Usually, but outbound is controlled | Often none |
| Updates | Northwind, any time | In the customer's change window | Customer installs a bundle |
| Managed services | Northwind's choice | The customer's cloud | Self-hosted |
Interfaces and Adapters
Write one contract test suite per interface (publish, consume, acknowledge, redeliver) and run it against every adapter. If the RabbitMQ adapter passes the same tests as the SQS adapter, product code cannot tell them apart.
Licences, Updates and Telemetry Offline
On-premises customers still need your fixes. Publish security updates for every supported version, keep a clear support window (for example the last three releases), and make database migrations safe to run by the customer's operators with no Northwind engineer present.
Try It: One Build for Cloud, Private Cloud and On-Premises
- Start with the cloud-first choices. Which profiles fail, and why?
- Change one dependency at a time. Which change fixes the private cloud profile?
- Find the choices that pass all three profiles.
Pass rule: every dependency works in all three profiles with the same build: no cloud-only service on-premises, no outbound calls the customer cannot control, and no separate build.
Multi-tenancy changes too. Globex's on-premises install has one tenant, so the tenant directory has one row and pooling saves nothing. Keep the tenant model anyway: the same code paths run everywhere, and the tests cover them.
Check Yourself
Common mistakes
| Mistake | Wrong | Correct | Why it happens |
|---|---|---|---|
| A forked edition | release-onprem branch | One build, config profiles | It is fastest for the first deal |
| Cloud SDK everywhere | sqs.sendMessage in 40 files | A queue interface, two adapters | The SDK is right there |
| Online-only licence | The app cannot start without internet | Signed licence file checked offline | Cloud was the only target |
| Forced telemetry | The app hangs trying to send metrics | Configurable: Northwind, customer collector, off | Nobody tested with no network |
| Untested profiles | On-premises breaks at the customer | Every profile in CI | Cloud tests are the only ones that run |
Practice
What to Remember
- One build; differences in config profiles and feature flags.
- Interfaces you own, with one adapter per environment, and contract tests for each.
- Open protocols where you can.
- Signed licence files and release bundles; telemetry the customer controls.
- The same tests in every profile, every release.
Further Reading
- The Twelve-Factor App: Config: keep what differs between deploys in config, not code.
- Martin Fowler: Feature Toggles: kinds of flags and how to manage them.
- Alistair Cockburn: Hexagonal architecture: ports and adapters, the idea behind swappable services.
Next: Case study: help desk (BoldDesk). You design a complete help desk on the canvas, reusing what the B2B modules built.