orboto Cloud
The fully managed way to run orboto - what the platform handles for you, and what stays identical to self-hosting.
orboto Cloud is the managed edition: the same product as self-hosted, operated for you. Your workspace lives at its own address, and the platform takes care of everything below the application layer - you sign up, and there is no server, container, or database for you to think about at any point afterwards.
What cloud manages
- Hosting and TLS. Your workspace runs on managed infrastructure and is reachable over HTTPS from the moment it's provisioned - there is no server to patch, no container image to pull, and no certificate to renew. Compare this with self-hosting, where you run Docker Compose yourself and put your own reverse proxy in front.
- Updates. New versions roll out to your workspace as non-interrupting updates by default - you don't see downtime, and you don't have to bump an image tag yourself. When a maintenance action genuinely could affect you (something more than a routine rolling update), you're notified in advance per the service terms before it happens. If your team needs to control exactly when a new version lands - for example to line it up with your own release testing - you can stay pinned to a specific version instead of following the rolling channel; ask support to set this for your workspace.
- Backups. The platform runs automatic backups of your workspace in the background, independently of anything you configure. On top of that, you keep the same self-service export tools as a self-hosted install: trigger a full backup on demand, or set up your own scheduled jobs against your own S3-compatible bucket, from Admin → Backup. Cloud does not remove this admin area - it adds a second, platform-side safety net on top of it.
- Email. Outbound email (invitations, notifications, password resets) works immediately with no setup - there is no SMTP host or API key to configure before your first invitation can be sent. If you'd rather use your own email provider (your own domain's deliverability, your own sending limits), you can still configure one exactly as a self-hosted install would, from Admin → System Settings → Email delivery.
- AI features. Managed AI can be turned on for your workspace without bringing your own OpenAI/Anthropic/Ollama key - the platform provides one. If you'd rather use your own provider account (your own usage billing, your own model choice), bring-your-own-key remains fully supported, configured the same way as self-hosted.
- Scaling and database tuning. Self-hosting exposes knobs like the number of API worker processes and Postgres memory settings so you can size an instance to your own hardware (see Scaling beyond one process). On cloud, none of that exists as a setting - the platform sizes and scales your workspace's resources for you as usage grows.
What is identical to self-hosting
| Area | Cloud | Self-hosted |
|---|---|---|
| Features, permissions, API | Same product, same behaviour | Same product, same behaviour |
| Data ownership | Full backup export, per-user data export, GDPR tooling | Full backup export, per-user data export, GDPR tooling |
| Email providers | Managed by default, or bring your own | You configure a provider yourself |
| AI features | Managed key available, or bring your own | Bring your own provider key |
| Admin surface | Same admin panel and settings | Same admin panel and settings |
Everything in the user guide and admin guide applies to cloud and self-hosted alike, down to individual permission slugs and API endpoints - there is no cloud-only or self-host-only feature gate on anything documented there. Where a page differs by edition it says so inline; a handful of operator-facing pages - running Docker, choosing a reverse proxy, tuning Postgres - only apply to self-hosting, because cloud simply has no equivalent step for you to take.
Your data
Your workspace's data is yours: full backup export, per-user data export and the GDPR tooling are available in cloud exactly as in self-hosted installations. Nothing about switching to cloud changes what you can export or delete, or locks anything behind a migration process - the same backup archive format that restores a self-hosted instance is what you'd take with you if you ever moved off cloud.
Troubleshooting
I can't find where to configure the server, domain, or database. Cause: those are exactly the pieces cloud manages for you - there is no equivalent setting to look for, by design. Fix: if you need infrastructure-level control (a private network, a specific region, custom scaling), that is a self-hosting decision - see Self-hosting. Everything else - projects, users, integrations, AI, notifications - is configured from the same Admin area cloud and self-hosted share.
I want an on-demand backup, not just the automatic platform one. Cause: the automatic platform backup runs on its own schedule and isn't something you trigger yourself. Fix: trigger and download your own export any time from Admin → Backup - available identically on cloud and self-hosted, and independent of the platform's own backups.
I want to stop using cloud and run this myself instead. Cause: not a limitation - just a decision to make once. Fix: export a full backup archive from Admin → Backup, then follow Self-hosting with Docker and restore that archive during first-run setup on your own instance.
Agents administration
Onboard a service account for coding agents, watch who's active, steer work with routing labels, pause runaway automation, and manage workspace rules.
orboto AI
The managed AI provider built into orboto - working AI features from day one, with no account or key from another company required.