Cloud infrastructure

Sencai is a control plane over cloud accounts you already own. You connect a provider account, Sencai discovers what is running in it, and from then on you can inspect and operate that infrastructure from one place instead of one console per provider.

This page is a map of the section. If you are setting up for the first time, start at Connect a cloud provider.

You bring the cloud account

There is no Sencai-hosted compute tier. Provisioning happens on your own provider account, billed by that provider directly to you, using credentials you supply. You keep ownership of the resources, the billing relationship, and the ability to walk away with your infrastructure intact.

If you want infrastructure without running your own cloud account, talk to your account team - that is a commercial arrangement, not a self-service option in the product.

Note

You do not need a cloud account at all to use the fleet agent. It runs on any Linux host you already have - bare metal, on-prem, or a VM someone else manages - and is a perfectly good place to start.

The one distinction that matters

Two different parts of the app look similar and do very different things. Getting them confused is the single easiest mistake to make here.

	Live cloud	Networking & Edge
Menu	Live cloud → Firewalls / Networks / DNS	Networks, DNS Zones, Policies, Templates
Acts on	Your real provider account	A record in Sencai’s database
Effect of a change	Immediate, real, and billable	Documents intent; changes nothing at the provider

So /gravity/live-cloud/firewalls opens a real firewall at your provider, while /gravity/networks/[id]/security-groups/[sgId] edits a Sencai row that describes one. Both are useful - the first for operating, the second for design and policy - but only one of them will lock you out of a server.

Each page in this section states which side it is on. Live-cloud write coverage differs per screen, so check the one you need rather than assuming:

Live cloud screen	Providers it writes to
DNS	AWS, Azure, Google Cloud, Cloudflare, Hetzner Cloud
Firewalls	Hetzner Cloud, AWS
Networks	Hetzner Cloud

Only Hetzner has been verified end to end across all three. Providers outside a screen’s list appear in discovery and inventory, but that screen returns a “not implemented” error for them rather than failing as though it were an outage.

Where to start

If you want to…	Go to
Connect your first account	Connect a cloud provider
Know what access to grant first	Permissions your credentials need
See what you already run	Import existing infrastructure
Create or operate a server	Provision & manage instances
Deploy from a template	Blueprints & the catalog

Operating what you have connected

• Networks & connectivity - real provider networks, subnets and routes, plus the separate design-record side.
• Firewalls & security groups - real provider firewalls and how to avoid locking yourself out.
• DNS - zones and records at your provider.
• TLS certificates - certificate inventory and expiry tracking.
• CDN - importing and managing an existing distribution.
• Backups & restore - snapshot policies and restore evidence.
• Regions & data residency - where workloads run and where platform data lives.

A sensible first hour

1. Connect one account with read-only credentials.
2. Run a discovery scan and look at what comes back.
3. Adopt only the resources you actually want managed.
4. Widen the credential to write access once you trust what you see.

Doing it in that order means the worst case of a misconfiguration is an incomplete inventory rather than an unintended change to production.

What’s next

• Connect a cloud provider - the starting point
• Permissions your credentials need - grant the narrowest access that works
• Core concepts - what a managed resource is and how async operations are tracked
• Cloud cost management - what the connected accounts are spending
• Fleet overview - the no-cloud-account-required path