Connect your cloud and take stock

This path is for someone who already runs infrastructure on a cloud provider and wants Sencai in front of it. You are not starting from an empty account, so the first job is not provisioning - it is seeing what you already have, without changing any of it.

By the end you will have a credential scoped to the narrowest access that works, a read-only discovery scan behind you, an inventory where every resource has an ownership decision recorded against it, and one instance that Sencai provisioned itself so you know the write path works too.

It assumes you have a Sencai account, an organization, and the Admin or Owner role in it. It also assumes you can create a credential in your provider’s own console - an IAM policy and access key, or an API token. On a production account that is often a different person, so start the conversation early.

Before you start

Three things to line up first.

Your role. Adding, validating, and removing cloud credentials, and running a discovery scan, need Admin or Owner. Adopting a discovered resource needs Member or higher; promoting one to a fully managed record needs Admin or higher. If you are an Auditor or Viewer you can read the results of this path but not perform it - see Roles and permissions.

Provider console access. Step 3 of the path is work you do at your provider, not in Sencai. Read it before you generate a key, because the policy you attach is the only thing that decides what Sencai can do.

Your plan. Plans cap how many managed resources an organization can have, and the New instance wizard tells you at step 1 if you have hit that cap. Resources you only track in inventory without managing do not count against it, so the discovery and triage half of this path is not what consumes your allowance - see Plans for what each tier includes, and sencai.space/pricing for the numbers.

The last step may show you an empty screen

Cost ingestion has to be enabled for your organization before Infrastructure → Cost Records (/gravity/costs) shows anything, and that is not a toggle you can flip yourself - ask your account team to confirm it is on for your environment. Not every connected provider has cost ingestion built for it either. Read Cloud cost management for what the screen does; do not treat an empty one as a failed step.

Note

If you have no cloud account at all, this is the wrong path. The fleet agent enrolls any Linux host - cloud, on-premise, or bare metal - with no provider account involved.

The path

The order is deliberate: everything that only reads comes before anything that writes, so the worst outcome of a mistake in the first half is an incomplete inventory rather than an unintended change to production. Steps 2 and 3 are the one place to read ahead - step 2 shows you what the credential form will ask for, but step 3 is what you act on first, in your provider’s console. Read both, then work backwards through them.

0 of 8 read

1. 1 Understand the model first You bring your own cloud account. Read the difference between screens that change your provider account and screens that only record something here. Open →
2. 2 Connect a provider account The exact fields each provider needs, how to validate the credential, and how to turn on scanning. Open →
3. 3 Scope the credential to least privilege Build the read-only policy before you create the key. This page carries a paste-ready AWS policy. A credential can validate successfully and still be under-privileged - the symptom is a short inventory rather than an error. Open →
4. 4 Run a read-only discovery scan Nothing at your provider changes. You get an inventory of what is already there. Open →
5. 5 Triage what the scan found Set ownership on each resource, fix missing tags, and acknowledge drift. Open →
6. 6 Provision something new The instance wizard, the states an instance moves through, and what each detail tab shows. Open →
7. 7 Record where workloads run Which provider region a workload is in, and what the Regions screen does and does not do. This screen is bookkeeping. Marking a primary or a replication target does not move or replicate anything. Open →
8. 8 See what it costs Where provider cost records come from and how often they refresh. Open →

What to watch out for

A green validation badge is not proof the credential can see anything. This is the single most expensive misunderstanding on this path. Validation proves the key is live; it does not survey what the key is allowed to read. On AWS the identity check it makes cannot be restricted by any policy at all, so a key with an empty policy still validates. Worse, a scan treats each service independently: a denial on one is recorded, skipped, and the scan still reports success. The symptom of an under-privileged credential is a short inventory, not an error. Judge the credential by the resource counts the first scan returns, and compare against a run with the full action list before trusting a trimmed policy.

Region coverage fails the same silent way. The AWS scan asks which regions are enabled and then sweeps all of them. If that one call is denied it falls back to the single region stored on the credential, and a one-region inventory looks exactly like a complete one.

Two providers where “read-only” is a promise nothing enforces

UpCloud’s credential is a full login and Vultr’s API keys are account-wide with no read-only scope - a key that can list instances can also delete them. On Scaleway, discovery is zone-scoped and the form has no zone field, so a credential for servers outside its default zone validates fine and returns an empty inventory with no error. On Linode, the in-app field hint is wrong in both directions: Read Only on Linodes is enough to scan, but you also need Account: Read Only or validation fails before the scan is ever attempted. Permissions your credentials need has the per-provider detail.

Adoption writes a tag at your provider, so a read-only credential cannot do it. Scanning and viewing are unaffected - it is the tag-injection step alone that fails, and unlike an under-privileged scan it fails loudly. The Ignore option adds no tags and changes nothing at the provider. If you want to finish the triage step on a read-only key, ignore what you do not want and leave the rest unmanaged until you widen access.

Adopt, promote, and provision are three different things. Adopting labels a resource and optionally tags it. Promoting creates a real managed record whose own screen can start, stop, and destroy the actual resource - but promoting itself changes nothing at that moment. One consequence catches people out: a server you promoted does not get the Sencai access account or the browser terminal that a freshly provisioned instance gets, because that setup only runs on an instance’s first boot, which already happened.

The Regions screen is bookkeeping and nothing else. Infrastructure → Regions (/gravity/infrastructure/regions) records which provider region you treat as primary and which one you would fail over to. Marking a primary provisions nothing; setting a replication target replicates nothing. The region identifier field is free text and is not checked against what your connected accounts can actually reach. The only region setting that decides where a workload physically runs is the one you pick in step 2 of the New instance wizard.

Two screen families, near-identical names, very different blast radius

Live cloud → Networks (/gravity/live-cloud/networks) and Live cloud → Firewalls (/gravity/live-cloud/firewalls) change your real provider account. Networks works against Hetzner Cloud only today; Firewalls also works against AWS. Networking & Edge → Networks (/gravity/networks) and its security group editor only write a row in Sencai’s own database; Networking & Edge → DNS Zones (/gravity/dns) is an explicit placeholder. If your account is with another provider, the live screens have nothing to show you even though provisioning instances on that provider works fine.

Do not make a blueprint your first provisioned instance. Deploying from Blueprints and the catalog records an instance but never asks which connected account to provision into, so the deployment sits at Provisioning indefinitely and never fails either. Use New instance for the final step of this path.

Automatic scanning is unattended periodic reading. It is off by default and re-reads the account on a recurring schedule once enabled, indefinitely, with nobody triggering it. Manual scans work whether or not it is on. On a customer’s production account, make it a decision rather than a default.

Nothing in Sencai enforces read-only. No part of the platform inspects a credential’s scope and refuses to use it for writes. If you hand over a full-access key, the provisioning screens will use it. The guarantee comes entirely from the policy or token scope you set at the provider - which is why step 3 exists.

What’s next

• Firewalls and security groups - the first live-cloud screen worth using once your inventory is trustworthy, on Hetzner Cloud and AWS
• Fleet overview - enroll the agent on the hosts you just inventoried for package, patch, and log visibility the provider API cannot give
• Policies - turn the tags you fixed during triage into a rule that flags the next resource that misses them
• Cost allocation - attribute spend to teams and projects using those same tags
• Learning paths - the other reading orders, including the fleet and security ones