Skip to content
Sencai.docs

Connect a cloud provider

To provision and manage cloud instances through Sencai, you connect a cloud provider account - your own cloud provider account. Instances then run on infrastructure you control and are billed directly by that provider, in addition to Sencai’s own platform fee.

Sencai can also provision and bill capacity on your organization’s behalf instead of you managing a provider account directly - one contract, one invoice, across providers. That path is arranged through your account team rather than a self-service toggle in the app today; ask if it’s a better fit than connecting your own account.

Supported providers

Section titled “Supported providers”

Sencai natively integrates with a broad set of providers, including AWS, Microsoft Azure, Google Cloud, Hetzner, DigitalOcean, Scaleway, OVHcloud, UpCloud, Oracle Cloud (OCI), Vultr, and Linode (Akamai). IBM Cloud support is in progress.

The Add Cloud Account screen shows the exact set of providers available to your organization; treat it as the source of truth.

Where credentials live

Section titled “Where credentials live”

Cloud provider credentials are managed on one screen: Settings → Cloud Credentials (/gravity/settings/cloud-credentials), scoped to whichever organization is active in the top switcher. Each row is one connected account - its name, provider, validation status, when it was last validated, and whether automatic scanning is turned on.

Adding, validating, or removing a credential requires the Admin or Owner role in the organization; other roles can view the list.

Adding your own credentials

Section titled “Adding your own credentials”

  1. Click Add Cloud Account.

  2. Give it a descriptive name - useful if you’re connecting more than one account for the same provider (for example, “Production AWS” and “Staging AWS”).

  3. Choose a provider. The form changes to ask for that provider’s own credential fields - typically an access key or API token you generate from the provider’s own console:

    ProviderFields
    AWSAccess Key ID, Secret Access Key, Region
    AzureSubscription ID, Tenant ID, Client ID, Client Secret
    Google CloudProject ID, Service Account Key (paste the full JSON key file)
    HetznerAPI Token
    DigitalOceanAPI Token, Region (optional)
    OVHcloudApplication Key, Application Secret, Consumer Key, Region (must be a numbered subregion such as GRA9, not a bare metro code like GRA)
    ScalewayAccess Key, Secret Key, Organization ID, Project ID
    UpCloudUsername, Password
    VultrAPI Key, Region (optional)
    Linode (Akamai)Personal Access Token (scoped to Linodes: Read/Write), Region (optional)
    Oracle Cloud (OCI)Tenancy OCID, User OCID, API Key Fingerprint, Private Key (PEM), Passphrase (optional), Region (optional), Compartment OCID

  4. Optionally turn on automatic scanning - Sencai will re-read this account’s resources on a recurring schedule and keep your inventory up to date. This only affects the scheduled scan; you can always trigger a manual scan regardless of this setting.

  5. Save.

Saving stores the credential immediately - it does not automatically check it against the provider. The new row shows as awaiting validation until you validate it.

Credential validation

Section titled “Credential validation”

Click Validate on a credential’s row to check it works. Sencai makes a read-only call to the provider using the stored credential and reports back:

  • Valid - the credential authenticated successfully.
  • Invalid - the provider rejected it (wrong key, revoked token, insufficient permissions, or similar). The error message from the provider is shown so you can tell what to fix.

A credential marked invalid is blocked from starting new provisioning or discovery scans until it validates successfully again - re-enter the correct value by adding a fresh credential (see below), since an existing credential’s secret value can’t be edited in place.

How credentials are scoped and stored

Section titled “How credentials are scoped and stored”

A credential belongs to exactly one organization - it’s never shared across organizations, even if you’re a member of more than one. Instances and scans that use it are billed and audited against that organization.

Credentials are encrypted at rest and are never displayed in full again once saved, including to Sencai staff. If you need to change a credential’s value, add a new one with the corrected value and remove the old one rather than trying to edit it in place.

Rotation policies

Section titled “Rotation policies”

Secrets → Rotation Policies (/gravity/secrets/rotation-policies) lets you set a reminder schedule for a credential - a rotation interval (30 to 365 days) and how many days ahead of the deadline to be warned. When a policy comes due, Sencai marks it Pending Rotation so it’s visible across the organization instead of depending on one person remembering.

Rotate Now on a policy triggers rotation immediately rather than waiting for the schedule. Treat this as a tracked reminder mechanism first: the most reliable way to actually replace a credential’s secret value today is still the same “add a new credential, remove the old one” pattern described above - generate the new key or token in your provider’s console, add it here, confirm it validates, then remove the credential it replaces.

Removing a credential

Section titled “Removing a credential”

Removing a credential does not affect instances that are already running - it only stops Sencai from being able to provision new resources or manage existing ones through that credential. Terminate or migrate any instances you no longer want managed before removing the credential that provisioned them, if you want them cleanly torn down through Sencai rather than left running unmanaged on the provider side.

What’s next

Section titled “What’s next”