Sign in How it works Get in touch

Infrastructure for employee‑built software

Extend your SDLC to non‑engineering teams, from first prompt to final audit.

Get in touch How it works

A screen of the Vibtra console for the example organisation Acme, cycling through five of its pages as the highlighted row moves down the sidebar: Dashboard, then Requests, then Connections, then Tools, then Receipts.

Connects to the systems your work already lives in

Google WorkspaceGoogle SheetsGoogle DriveOktaPostgreSQLMySQLDatabricksMetabaseSnowflakeJiraConfluenceNotionAirtableHubSpotXeroDatadogmonday.comVercelNetlifyCloudflare Workers1PasswordStripeGitHub

Vendor marks identify the systems Vibtra connects to. They remain their owners’ trademarks and imply no endorsement or affiliation.

Six parts, one console

A sign-in gate, a vault, a rulepack, a policy document, an agent door and your own cloud. Each of them is a page your people can open.

Who can open it

Audience1 groupEnforced at the sign-in gate, on the next sign-in.
GroupsFinance
Aada@acme.exampleAda
Ccarol@acme.exampleCarol

One sign-in in front of every internal tool

Nobody gets a second password. A tool your people built opens behind the same gate as everything else, and its audience is a group rather than a list somebody has to keep.

Who can open a tool
SlackREST API (key in a header) · slack Managed
Credential sourceop://Engineering/Slack/bot-tokenRead from your own 1Password at each use. Vibtra stores the reference, never the value.
Token••••••••••
Probeok · the credential works
Used byExpense approvalsDisplay names, from the ledger. Never a value, never a variable, never a host.

The tool never holds the credential

It holds a reference. The value is sealed in your organisation’s vault, or read from your own 1Password at each use and stored nowhere, then resolved into a deploy at the moment it needs one.

What happens to a credential
Expense approvals14 Sept 2026, 3:41 pm · rcpt_4c1f8a90d233 LIVE
✓No hardcoded secrets
✓No requests to non-allowlisted origins
✓No dangerous HTML injection
✓No dynamic code execution
✓No PII in console logs
✓No insecure http:// URLs
✓No module-scope side effects
✓No writes outside the editable surface

Every deploy leaves a record

Eight checks, all named, run before anything is sent. What they answered is sealed into a receipt, and the audit log it lands in is append-only. Nothing in this product edits it.

What the eight checks are

Which clouds a deploy may reach

The set of deploy targets this organisation allows.

Who may deploy

Any member
Owners and adminsA member’s deploy is refused at the intake, and so is their Redeploy.
Refused This org’s policy allows only owners and admins to deploy Nothing was built and nothing was sent.

Your policy, enforced on the deploy

Six rules an admin sets and this registry enforces at the intake, not in a review. Every change is versioned and lands in the audit log.

What Vibtra itself sees

Any terminal

claude mcp add vibtra \
  --env VIBTRA_REGISTRY_URL=https://vibtra.app \
  --env VIBTRA_REGISTRY_TOKEN=vbt_YOUR_TOKEN \
  -- npx -y @vibtra/mcp

`claude mcp list` shows vibtra; inside a session, /mcp lists its 9 tools.

In the agent’s session

> vibtra_deploy({ projectDir,
    appName, audience })
  LIVE · rcpt_4c1f8a90d233
C Claude Codeada@acme.example · last took a credential 3:41 pm Live

The agent is just a client

It pairs the way anything else does: one command, a door token minted in your console, and the same rules on it as on a person. Revoke the token and the door stops opening.

How an agent connects
ProductionVercel · the Vercel team Acme Ready
CredentialYour accountAdded by this organisation and sealed by Vibtra.
N V C

or wherever you host

It runs in your cloud, under your account

A deploy goes to your Vercel, Netlify or Cloudflare with a token your organisation added and Vibtra sealed. The tool your people built lives on your bill, not ours.

Where a tool deploys

Plans

Team

Talk to us

Where a first organisation starts:

  • The sign-in gate and audiences
  • The organisation vault
  • Ledger and receipts
  • Every deploy target
  • Agent pairing over MCP
Talk to us
Most teams

Business

Talk to us

All of Team, and:

  • Your own OIDC identity provider
  • Groups as audiences
  • 1Password references in the vault
  • Database credentials minted per use
Talk to us

Enterprise

Talk to us

All of Business, and:

  • SCIM provisioning
  • Residency in writing
  • A security review with us
  • Connector work on your systems
Talk to us

FAQs

Where do our tools actually run?

In your own cloud account. A deploy goes to your Vercel, Netlify or Cloudflare, using a token your organisation added and Vibtra sealed. Vibtra’s own control plane is built for Sydney (ap-southeast-2) and is not deployed yet; your tool would never run on it in any case.

What does Vibtra itself see?

What it was given: the records of what was deployed, the credentials you sealed, and the sign-in decisions it made. It is not in your tool’s data path. The one hop it sits on is the sign-in gate. When the console inspects a connected system it reads object names, field names and field types, never a row of data.

Who can open a tool once it is deployed?

Whoever its audience says: the whole organisation, a named group, or named people. You change it in the console and it takes effect at the next sign-in, with no redeploy, and nothing about a person is ever compiled into the app. Someone left out can ask for access, and the approval runs the same rule the form does.

What happens to a credential?

It is sealed in your organisation’s vault and resolved into a deploy’s environment at the moment that deploy needs it, after the audience is checked. You can point a connection at an item in your own 1Password instead, which is read at each use and stored nowhere. On Postgres and MySQL, Vibtra can hand the whole problem to OpenBao, which mints a database user per use with an expiry, after which we hold no password at all.

Does it replace our cloud accounts or our identity provider?

Neither. Deploys land in the cloud accounts you already have, and sign-in is Google or an OIDC provider you register, Okta and Microsoft Entra ID among them. Vibtra sits between the two and keeps the record.

What happens when someone leaves?

Every tool has an owner, and an owner can be changed, which writes its own record naming who handed it to whom. A tool nobody needs any more is archived, which closes its sign-in gate. Neither act deletes any history.

Can we run Vibtra ourselves?

Not today, and we would rather say so than imply otherwise. There is no self-hosted image at launch. Residency is answered by hosting in Sydney (ap-southeast-2), which is what the control plane is built for; if running it inside your own estate is a requirement, that is a conversation to have with us rather than a download.

Deploy with Vibtra

We set up organisations one at a time. Tell us about yours.

Get in touch