Inventory and provisioning
Most infrastructure problems start with not knowing what you actually have. Sencai reads what's already running the moment you connect a cloud account — instances, networks, storage, DNS — with no migration and no waiting period, and shows the same inventory for any Linux server, cloud or bare metal, once the fleet agent is running on it. From there, the same console starts, stops, resizes, and destroys resources across providers, using one workflow instead of eleven different ones. What you see is never a stale copy: for DNS, firewall, and network changes, Sencai acts on the provider directly.
What shows up the moment you connect
Connect a cloud account and Sencai reads what's already running: instances, networks, storage volumes, DNS zones. This happens the moment credentials are added — there is no import step, no waiting period, no requirement to move anything first. Discovery is read-only by default. Nothing comes under active management until you decide it should, resource by resource, so a first connection never risks touching production by accident. This matters most for infrastructure nobody has a full map of anymore: accounts opened years ago by people who have since left, servers provisioned for a project that shipped and was forgotten, DNS zones nobody remembers registering. Connecting the account is enough to see all of it in one inventory, normalized the same way regardless of which provider it sits on. You can stop there and just have a map, or start bringing individual resources under management — start/stop, resize, DNS, firewall rules — one at a time, at your own pace.
Eleven providers, one console
Sencai connects to Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode, and Oracle Cloud — see the full list under integrations — plus any Linux server you run yourself, cloud or bare metal, through a lightweight fleet agent. Provisioning, starting, stopping, resizing, and destroying an instance is the same workflow no matter which of those it runs on, so your team stops context-switching between eleven consoles with eleven different mental models. That consistency extends to how resources are represented, not just how they're operated. An EC2 instance, a Hetzner Cloud server, and an Azure VM show up as the same kind of thing with the same fields, so the inventory reads as one system instead of eleven exports stitched together by hand. For a team running mixed infrastructure — a bit of AWS for one client, Hetzner for the rest, a handful of bare-metal boxes in a colo — that normalization is most of the value: one place to look, one way to act, regardless of who's billing for the compute underneath.
Provisioning, at the resource you actually chose
Once a resource is under active management, the same console starts it, stops it, resizes it, or destroys it — the same actions, the same workflow, whether it's an instance you provisioned through Sencai or one that was already running when you connected the account. There is no separate path for resources Sencai created versus resources it found; opting a resource into management is what matters, not its origin. Management is granted resource by resource, never account-wide. Connecting an account never puts everything under Sencai's control automatically — you choose which instances, which networks, which storage volumes are actively managed, and everything else stays visible in inventory without being touched. That's deliberate: teams with production infrastructure they want left alone and dev or test infrastructure they want automated need to draw that line resource by resource, not provider by provider. The lifecycle workflow itself doesn't change based on where you draw it — starting, stopping, resizing, and destroying work the same way either side of that line.
Live control, not a cached copy
For DNS records, firewall and security-group rules, and virtual networks, actions in Sencai happen synchronously at the provider itself, not against a stored copy of your configuration that catches up later. Change a firewall rule and that change happens at the provider immediately; what you see afterward reflects the provider's actual current state, not the last time Sencai happened to sync. How deep that live control goes varies by capability and by provider, and we say so plainly rather than blur the line. DNS, firewall, and network management are three separate capabilities, not one feature wearing three names, and coverage is not identical across providers for any of them — some providers support live, synchronous control today for one of the three and not yet the other two. That's Sencai's own coverage catching up, not a ceiling set by the provider, and we're extending it provider by provider rather than promising all of it at once — see integrations for what's live today on each one.
Bring your own cloud, or let Sencai hold the account
Most teams start BYOC: you connect an existing account, your contract and billing relationship with the provider stays exactly where it is, and Sencai never migrates anything. Credentials are encrypted at rest, and access can be revoked at the provider at any time — disconnecting Sencai is as final as revoking any other integration's API key. For teams that would rather not hold a direct account with every provider they use, Sencai can provision and bill that capacity under its own account instead. You get one contract and one invoice covering infrastructure that may span several providers, priced at what the provider charges plus a 2% margin, shown as its own line on the statement rather than folded into a larger number. The two models coexist inside the same organisation: start BYOC and add managed capacity for a new provider later, or start managed and bring an existing account in as BYOC once it makes sense. Neither path is a dead end for the other.
A record of who changed what
Every action taken through Sencai — a resize, a destroyed instance, a firewall rule changed, an account connected — writes to an append-only, hash-chained audit log. Entries can't be edited or deleted after the fact; the chain itself is the proof. "Who changed this, and when" becomes something you query in seconds instead of something you reconstruct from provider consoles and chat history afterward. That record is what most security reviews and incident retrospectives actually need, and it's built into inventory and provisioning rather than bolted on separately — every discovery scan, every lifecycle action, every live change at the provider already lands in the same chain. For the fuller compliance and evidence story, including what Sencai hands over in place of a certificate it doesn't hold, see security and compliance.
See your infrastructure in one place
Connect an account on the free plan — one user, one organisation, five managed resources, no card required — or start a 14-day full-featured trial. Most teams have their first deploy running in under 30 minutes.