Skip to content
Sencai.docs

Connect a cloud provider

To provision and manage cloud instances, Sencai needs a cloud provider account to work with. The default, fastest way to get one is a Sencai account - Sencai owns the account with the provider and bills its cost back to you, plus a fee, with your resources kept safely separated from every other organization sharing that account. See Sencai accounts for how to turn one on, what it costs, and its spend cap and non-payment rules.

This page covers the advanced option: connecting your own cloud provider account instead. Instances then run on infrastructure you control and are billed directly by that provider, in addition to Sencai’s own platform fee. Both options live side by side on the same Settings → Cloud Credentials screen, and different instances can use different ones.

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:

    Provider Fields
    AWS Access Key ID, Secret Access Key, Region
    Azure Subscription ID, Tenant ID, Client ID, Client Secret
    Google Cloud Project ID, Service Account Key (paste the full JSON key file)
    Hetzner API Token
    DigitalOcean API Token, Region (optional)
    OVHcloud Application Key, Application Secret, Consumer Key, Region (must be a numbered subregion such as GRA9, not a bare metro code like GRA)
    Scaleway Access Key, Secret Key, Organization ID, Project ID
    UpCloud Username, Password
    Vultr API 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”