"Fully managed" means very different things depending on who's selling it. This article explains what RoamerHost actually does — not marketing language, but the parameters genuinely applied when each instance is created.
The 30-Second Overview
| Item | Details |
|---|---|
| Deployment | One subscription = one isolated Docker container |
| Isolation | A dedicated network, not shared with other customers |
| Credential protection | AES-256 encryption |
| Address | A dedicated subdomain, with support for a custom domain |
| SSL | Issued and renewed automatically |
One Instance = One Isolated Container, Not a Shared Account
The usual approach on cheap shared hosting is to put many accounts on one machine, all sharing the same PHP, the same database service, the same configuration. When a neighbor's traffic blows up, your site slows down with it.
Every time RoamerHost creates an instance, it runs docker run for a dedicated container with these key parameters:
| Parameter | What it does |
|---|---|
--memory / --memory-swap | A hard memory cap. Setting both to the same value means swap is never used — the memory reserved for you is all physical memory, not disk pretending to be memory. |
--cpus | A hard CPU cap. A plan marked 1.5 gets 1.5 cores' worth of compute, not "up to." |
--network | A dedicated Docker network per instance (named {container-name}-net), so containers cannot reach each other by default. |
--security-opt=no-new-privileges | Stops processes inside the container from gaining extra permissions, so even a compromise at the application layer can't escalate via setuid. |
--restart=unless-stopped | Brings the container back up after a process crash or a host reboot, with no manual intervention. |
Hard limits cut both ways, and that's worth spelling out. The upside is that your resources can't be eaten by a neighbor; the downside is that over the limit is over the limit — when memory runs out, processes in the container are killed by the OOM killer rather than quietly stealing from someone else. That's a deliberate trade-off: we'd rather you see a clear resource shortage in monitoring and upgrade your plan than let one runaway instance drag down the whole machine.
SSL: A Wildcard Certificate, Not One per Site
All *.roamerhost.com subdomains share a single wildcard certificate, managed by the Traefik reverse proxy and renewed automatically 30 days before expiry after DNS API validation. That means HTTPS works the moment you spin up a new instance — no waiting for a certificate to be issued, and no "first request for a new domain hit a rate limit" surprises.
On the platform side, a certificate health check runs every Monday at 09:00, verifying the wildcard certificate's remaining days and the state of the DNS API key. Fewer than 21 days remaining means automatic renewal has failed, and an alert email goes out immediately — because under normal conditions renewal should already have completed at the 30-day mark.
Expiry Doesn't Delete Your Data Immediately
What happens after a subscription expires or is cancelled is staged, not abrupt:
- Running as normal on the expiry date: the instance works all day on the day it expires, and renewing during this window changes nothing.
- Suspension the day after expiry:
docker stopruns, so the container halts but the data volume is kept intact. Renew at this point and everything is exactly as you left it once it starts again. - Deletion after 3 months of suspension:
docker rmruns and the data is erased for good.
In other words, there are 3 months of cushion between expiry and data actually disappearing. The platform checks expiry status hourly.
Who This Architecture Suits — and Who It Doesn't
A good fit: people who want an isolated environment without running a server themselves. You get isolation close to self-hosting (your own container, your own network, your own resources) without having to handle OS updates, certificate renewals, or reverse proxy configuration.
Not a fit: anything that needs root to change system-level settings, custom kernel parameters, or a multi-machine cluster. For those, contact us directly to discuss rather than buying a standard plan and trying to make it work afterward.
Subscriptions and Your Data
A few boundaries we get asked about in practice:
- Cancelling doesn't erase your data immediately — see the retention periods in the platform FAQ
- Upgrading doesn't wipe your data — services with a higher plan upgrade in one click from the dashboard and keep the same instance; there is no self-service downgrade
- A restart is not the same as a wipe-and-rebuild — the first leaves your data alone, the second clears it
The advice in all cases is the same: don't keep important data in only one place. Every service has an export path, and regular backups cost very little.
What "Fully Managed" Actually Covers
| Item | Whose job |
|---|---|
| Installation and initial setup | The platform |
| OS and environment updates | The platform |
| SSL certificate issuance and renewal | The platform |
| Container monitoring and auto-restart | The platform |
| How you use the application itself | You |
| Your data and configuration | You |
Those last two rows are the boundary. Managed hosting solves "the environment this tool runs in," not "how to use this tool." Getting n8n up and designing automations worth having are two different things.
Why One Container per Subscription
It isn't to charge more. It's because sharing creates three real problems:
- Resource contention — someone else's runaway workflow slows you down
- Credentials side by side — your API keys sit in the same environment as someone else's
- Locked-in versions — upgrades have to happen for everyone at once
An isolated container solves all three at once, at the cost of billing each service separately.
FAQ
Q: Can I subscribe to several services at the same time?
Yes — each is billed separately and none affects the others. Very common combinations in practice are n8n plus NocoDB, or Dify plus n8n.
Q: Are the listed resource numbers a guarantee or a cap?
That's covered in full in the platform FAQ, including what happens when memory is exceeded.
Q: Can I take my data with me?
Yes — every service has its own export path. It's worth confirming that once before you actually need it, since that's the key test of whether you're locked in.
Q: Who handles it when a service breaks?
Environment-level problems are ours (containers, networking, SSL); application-level configuration problems are yours to debug. The dividing line is usually "does a restart fix it?"
Q: How is this different from renting my own VPS?
A VPS gives you complete control and hands you all of the operations work. Managed hosting trades away some control in exchange for not having to do that work. Cost comparisons for each service are in the corresponding "self-hosted vs. managed" articles.
Further Reading
- Subscriptions, Resources, and Instance Management: Questions Common to Every Service
- The Boundaries of Fully Managed WordPress: What You Can't Do, and Whether It Matters
- WordPress Hosting Pre-Purchase FAQ: Migration, Multiple Sites, and Traffic
- Technical Architecture by Product
- Full Plans and Pricing
Want Someone to Build It for You?
If you'd rather not build these workflows yourself, or the scope is big enough that you want help planning them, Roamer Tech (RoamerHost's parent company) takes on contract work for business process automation and AI agents:
