Sencai documentation

What Sencai does

Four things, in the order most organizations adopt them. Each one works on its own - you do not have to take all of it.

The cloud accounts you already have → Connect a provider account with read-only credentials, scan what is already running, and choose which of it Sencai manages. Nothing at your provider changes until you ask it to. Your own servers, in the same place → Install one agent on any Linux host - cloud, bare metal or on-premise - and it reports telemetry, installed packages, patch state and a hardening score back to the same console. Evidence, not just settings → Every action that changes something is written to an append-only, hash-chained audit log. The same log is what the compliance views read from when you need to show your work. What it costs, before the invoice → Provider cost records, allocation by tag, right-sizing candidates and forecasts - kept separate from what you pay Sencai, which lives under Billing.

Not sure where to start?

Three questions. The answers build a reading order out of pages that already exist - nothing is generated, and the same answers always give the same result.

1 What do you want to do first?

Connect a cloud account See what is already running at a provider, then manage it. Manage servers I already run Put an agent on Linux hosts, wherever they live. Show that what we run is secure Audit trail, access control and compliance evidence. Automate it from my own tools The API, tokens, and AI clients over MCP.

2 What are you running today?

Public cloud Our own servers Kubernetes A mix of all of it

3 Who are you doing this for?

My own team Customers we manage

Answer the first question and a reading order appears here. Or skip it and browse all six learning paths.

Learning paths

Ordered routes through the documentation, each one written for a particular job. Every step is a page you can also reach on its own.

All paths ›

Get started with Sencai → Account, two-factor, the object model, your first organization, and who gets which role. Learning path ·7 pages ·New accounts Connect your cloud and take stock → Add a provider account read-only, scan what is already there, triage the inventory, then provision something new. Learning path ·8 pages ·Cloud operators Run a Linux fleet → Enroll the agent, read what it collects, search packages across every host, and check hardening scores. Learning path ·8 pages ·Fleet operators The day-2 operations loop → Monitoring, incidents, root-cause candidates, runbooks and change control, in the order they depend on each other. Learning path ·8 pages ·On-call teams Security and compliance evidence → The audit log, access restrictions, single sign-on, and the inventory that every compliance view reads from. Learning path ·9 pages ·Security and compliance Build against the platform → The API surface and its conventions, scoped tokens, versioning, MCP for AI clients, and the developer tooling. Learning path ·8 pages ·Developers

Your setup checklist

The twelve things worth doing in your first week, in the order that avoids rework. Ticks are saved in this browser, so you can come back to it.

0 of 12 done

1. 1 Create and verify your account Sign up, or accept an invitation, then confirm the email before anything else. Open →
2. 2 Turn on two-factor authentication Enable TOTP on your own account while it is still empty. Open →
3. 3 Learn the object model What an organization, a managed resource, an agent and an audit event each mean. Open →
4. 4 Create your organization Credentials, agents, billing and audit all hang off it. Merging and splitting are irreversible. Open →
5. 5 Know what your plans cover Your organization's plan sets how many members it can have. Your personal plan governs how many organizations you may own, and which AI features you get - it never caps an organization's members. Open →
6. 6 Pick roles, then invite your team Owner, Admin, Member, Auditor, Viewer - and a per-resource overlay that can only subtract access. Open →
7. 7 Know your organization plan and trial clock The trial ends by blocking specific actions. Find out which ones before it does. Open →
8. 8 Scope a cloud credential to least privilege Build the read-only policy first, then create the key - not the other way round. Open →
9. 9 Connect the cloud account Add the credential, validate it, turn on scanning, and set yourself a rotation reminder. Open →
10. 10 Run a read-only discovery scan Nothing at your provider changes. You get an inventory to triage. Open →
11. 11 Set your notification preferences Decide what reaches you, and how, before the first alert fires. Open →
12. 12 Sign your Data Processing Agreement The GDPR Article 28 agreement is self-service, per organization. Open →

Tutorials

One sitting, one outcome. Each of these ends with something real: a working account, a validated credential, an enrolled host, a successful API call.

All tutorials ›

Your first 30 minutes → End with a verified, two-factor-protected account inside an organization you own, and know what your plan lets you do next. Tutorial ·6 steps ·~30 min Connect AWS read-only and produce your first inventory → Build a least-privilege policy, validate the credential, run one discovery scan, and give everything it finds an ownership state. Tutorial ·6 steps ·~45 min Enroll your first Linux host → Install the agent, confirm it is heartbeating, grant it the inventory capability, and read its hardening score. Tutorial ·5 steps ·~25 min Create a token and make your first API call → Create a scoped personal access token, make one authenticated request, understand the version headers, then revoke the token. Tutorial ·5 steps ·~15 min

Use cases

Whole scenarios rather than single screens, with the pages that answer each one in the order you need them.

All use cases ›

We inherited a cloud account and need to know what is in it → Read-only credentials, one discovery scan, and an inventory you can triage - without changing anything at the provider. Operate our Hetzner footprint from one place → Networks, firewalls, DNS and instances managed against the real provider account rather than recorded in a table. Live network changes are Hetzner Cloud only; firewalls also cover AWS, and DNS covers five providers. Keep a Linux fleet inventoried and measured → One agent per host, package search across the whole estate, patch-scan results and a per-host hardening score. Make monthly cloud spend visible and attributed → Where the cost records come from, how to split them by tag, and which right-sizing candidates are worth acting on. Spend caps record a limit and send alerts; they do not stop provider spend on their own. Hand an auditor read-only evidence → The hash-chained audit log, the inventory behind it, and the filtered NIS2 timeline you can export. Onboard the whole company through your identity provider → Single sign-on, SCIM provisioning, the synced directory it produces, and the events worth watching. Single sign-on and SCIM require a Business plan or above.

Browse by area

The same grouping the application's own navigation uses, so a screen you are looking at and the page that documents it share a name.

Cloud infrastructure → Provider accounts, credential permissions, importing, instances, networks, firewalls, DNS, certificates and backups. Fleet → Agent enrollment, telemetry, software inventory, patch state, remote execution, the browser terminal and Kubernetes. Security → Vulnerabilities, hardening scores, secret findings, access management, IP allowlist, edge protection and the audit log. Compliance and governance → Policies and scoring, NIS2 evidence, the EU AI Act queue, inventory ownership, approvals, privacy and agreements. Operations → Monitoring, incidents, runbooks, auto-remediation, synthetic checks, deployments, change requests and notifications. Cloud costs → Where cost records come from, allocation and showback, right-sizing, forecasts, anomalies and spend caps. Identity and access → Single sign-on, SCIM provisioning, the synced workspace directory, the identity watchdog and account security. API and automation → The platform API and its conventions, personal access tokens, webhooks, versioning and AI agents over MCP. Billing and plans → Organization tiers, personal plans, the trial, payment and invoices, and the referral program.

When you are stuck

The pages people open again and again, and the way to reach a person when they are not enough.

Troubleshooting → Symptom-first fixes across sign-in, invitations, credentials, scans, agents, the API and webhooks. FAQ → Short answers on providers, data residency, trials, on-premise and support, each linking to the full page. Glossary → Around 35 product terms, defined once, so the rest of the documentation can use them plainly. Finding your way around → Every group in the application's sidebar, and which page here documents it. Credential permissions → Exactly what access each provider's credentials need, and why read-only first is the right start. Getting help → Raising a ticket with the right category and priority, and what the response targets are.