CHANGELOG

Captivo Access changelog — 2026 · Page 3 of 13

What changed in vendor access, release by release, newest first.

v1.11.1

What's new in 1.11.1

  • Changed: the Access mark and accent colour moved to the product's own teal.

v1.11.0

What's new in 1.11.0

  • New: a platform console for operators. Each tenant has a detail page with a snapshot, alerts, health, lifecycle actions and export, alongside Activity, Admins, Jobs and Settings pages, an announcement banner and scheduled platform jobs.
  • New: support access (break-glass) into a workspace when its own administrators cannot get in, capabilities and limits set per workspace, and self-service sign-up that can be opened or closed.

v1.10.13

What's new in 1.10.13

  • New: people enter their real display name when they enrol, and can change it themselves afterwards.
  • Changed: on Cloud the self-hosted domain page is hidden, because it does not apply there.

v1.10.12

What's new in 1.10.12

  • Fixed: invitation links, the console links in e-mails and the OIDC redirect address all point at your own workspace address instead of a shared one.

v1.10.11

What's new in 1.10.11

  • New: enrolling an authenticator app shows a QR code to scan, instead of a code to type by hand.

v1.10.10

What's new in 1.10.10

  • New: the platform console shows times in a chosen display timezone, set on its preferences page.

v1.10.9

What's new in 1.10.9

  • New: one display timezone is used everywhere — date inputs, the portal, filters and the remaining places that still showed a raw time.
  • Fixed: the keystroke timeline is offered only when recording is actually on for that session, including when a policy forces it.

v1.10.8

Captivo Access v1.10.8

  • Recording policy — a new organization-wide recording mode on Policy

(Off / Per resource / Required): force-record every session for compliance,

leave it to each resource's own toggle, or disable recording entirely. Under

"Per resource" the per-Resource "Record sessions" toggle is honored as before.

  • Capabilities on by default — the Pro capabilities (remote-desktop gateway,

isolated browser, session recording, credential vault) now ship **enabled out of

the box*; disable any with its _ENABLED/NATIVE_GATEWAY flag set to 0.

  • Internal reliability fixes.

Straight image bump; the additive schema change is applied automatically on start.

v1.10.7

Captivo Access v1.10.7

Internal reliability release.

  • Request-scoping hardening across the admin console, portal, and API entry points, so every request's database work is consistently scoped to the correct context.
  • Test-suite alignment and additional regression coverage.

No changes to self-host behavior or configuration — upgrading is a straight image bump.

v1.10.6

Bring-your-own domain (invisible groundwork)

For the multi-tenant hosted edition, a tenant can serve a resource on its own domain (managed/BYO toggle + DNS verification + automated per-host TLS), alongside the managed per-tenant subdomain. Self-hosted is unchanged — the custom-hostname option uses the existing on-demand TLS path; managed resources are byte-identical.

v1.10.5

Per-tenant resource subdomains (invisible groundwork)

For the multi-tenant hosted edition, each vendor resource is now a subdomain of its tenant (<label>.<tenant>.<domain>), giving every tenant an isolated namespace. Self-hosted is unchanged — a single-tenant install keeps label.<your-domain>.

v1.10.4

Per-tenant resource hostnames (invisible groundwork)

For the multi-tenant hosted edition, each tenant now gets its own hostname namespace: the tenant identifier is embedded in the resource's subdomain label automatically, so different tenants can use the same short name without collision. Self-hosted is unchanged — a single-tenant install keeps label.<your-domain> exactly as before.

v1.10.3

Simpler resource hostnames

When adding a vendor resource, you now enter just the subdomain label (e.g. wiki) — the field shows your access-domain suffix automatically and assembles the full hostname for you. Less typing, no typos, and the resource always lands under the domain that's actually configured.

No behavioral change to existing resources; the full hostname is unchanged under the hood.

v1.10.2

Multi-tenant polish (invisible groundwork)

Internal fixes for the hosted-edition control plane. Invisible and behavior-preserving for the self-hosted product (dormant with MULTI_TENANT unset).

  • Vendor-resource hostnames are now enforced unique across tenants (routing correctness under a shared wildcard domain).
  • The internal sentinel tenant is hidden from the platform tenant list and skipped by scheduled jobs.

No change to the self-hosted product. Verified against the full test suite with the flag off.

v1.10.1

Console polish (invisible groundwork)

Small internal fixes for the multi-tenant hosted-edition console. Invisible and behavior-preserving for the self-hosted product — dormant with MULTI_TENANT unset.

  • The tenant-creation flow now returns a ready-to-use invite URL for the first admin.
  • Platform super-admins are routed straight to the platform console after sign-in.

No change to the self-hosted product. Verified against the full test suite with the flag off.

v1.10.0

Console-domain resolution (invisible groundwork)

Internal groundwork for the future multi-tenant hosted edition. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset) and the install runs exactly as before.

Added

  • An optional CONSOLE_DOMAIN for deployments that serve the console and the per-resource vendor proxy on different domains; unset by default, so the self-hosted product resolves exactly as it did (single domain). A couple of reserved subdomain labels were added alongside it.

No change to the self-hosted console, login, sessions, recordings, connector enrollment, audit, or scheduled jobs. Verified against the full test suite with the flag off.

v1.9.0

Request scoping (invisible groundwork)

Completes the request-scoping layer for a future multi-tenant hosted edition, so that with multi-tenancy enabled every request — console, data-plane, and scheduled job — operates only on its own tenant's data. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset), and the install runs exactly as before.

Added

  • Automatic tenant scoping for request-handling database access when multi-tenancy is enabled, so console pages and API routes are confined to the request's tenant without per-endpoint wiring.
  • Explicit tenant resolution for the parts that have no browser context: the data-plane's internal API (each request scoped from its payload, behind the existing shared-secret check), connector authentication and enrollment, and the scheduled maintenance jobs (which now run once per tenant). New database lookup functions back this, installed but unused on the self-hosted product.
  • A build-time guard that fails the pipeline if a future internal endpoint is added without declaring its tenant scope.

All of it is dormant on the self-hosted product (the single-tenant path is unchanged; the new functions install unused), and is covered end-to-end by automated multi-tenant isolation tests in CI. The self-hosted console, login, sessions, recordings, connector enrollment, audit trail, and scheduled jobs behave exactly as before. Verified against a copy of production before release.

v1.8.0

Platform control plane (invisible groundwork)

Adds the tenant-management control plane for a future multi-tenant hosted edition. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset), and the install runs exactly as before.

Added

  • A reserved platform tenant and a new Platform super-admin role that can create, list, and suspend/reactivate tenants, provisioning each new tenant's first administrator through the existing invite flow. Reuses the current passkey, session, and invite machinery — no separate sign-in stack.
  • A small platform console for those operations, and platform-aware first-run so the first account on the hosted edition is a platform administrator.
  • All of it is dormant on the self-hosted product: the platform console and role do not exist while multi-tenancy is off, and the tenant-management database functions install unused. Covered by an automated end-to-end provisioning test in CI.

The self-hosted first-run, console, login, sessions, recordings, and audit are unchanged. Verified against a copy of production before release.

v1.7.0

Tenant resolution machinery (invisible groundwork)

Continues the internal groundwork for a future multi-tenant hosted edition. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset) and the install runs exactly as before.

Added

  • The ability to resolve which tenant a request belongs to from its host (subdomain), and helpers that scope a request's database work to that tenant when multi-tenancy is enabled. Dormant on the self-hosted product (the resolver functions are installed but unused; the request wrappers pass through unchanged).
  • A cross-tenant resolution integration test in CI.

No change to the self-hosted console, login, sessions, recordings, or audit. Verified against a copy of production before release.

v1.6.0

Tenant isolation runtime (invisible groundwork)

Adds the internal machinery that makes tenant isolation enforceable for a future multi-tenant hosted edition. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset), the install connects as the database owner exactly as before, and nothing changes.

Added

  • A request-scoped tenant context: when multi-tenancy is enabled, each request runs in a transaction that pins the active tenant, so the Row-Level Security policies (shipped earlier) actually scope every read, and a database trigger stamps the tenant on every insert. All connection-bound and leak-proof.
  • These are dormant on the self-hosted product (the owner role bypasses RLS and the trigger is a no-op), and are exercised by an automated cross-tenant isolation test in CI.

No change to the self-hosted console, login, sessions, recordings, or audit. Verified against a copy of production before release.

v1.5.0

Tenant isolation layer (invisible groundwork)

Completes the internal tenant-isolation groundwork for a future multi-tenant hosted edition. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset) and the install runs exactly as before.

Added

  • Row-Level Security policies on every table (installed but dormant). The self-hosted install connects as the database owner, which bypasses RLS, so behavior is unchanged; the policies become the isolation boundary only when the multi-tenant runtime is turned on in a later release.
  • An ORM-layer tenant filter that scopes list/query operations to the active tenant when multi-tenancy is enabled (no effect when off).
  • A cross-tenant isolation integration test (runs against a live Postgres in CI) proving the policies isolate correctly.

Nothing in the self-hosted console, login, sessions, recordings, or audit changes. Verified against a copy of production before release.

v1.4.0

Tenant schema hardening (invisible groundwork)

Continues the internal groundwork for a future multi-tenant hosted edition. Invisible and behavior-preserving for the self-hosted product — multi-tenancy stays off (MULTI_TENANT unset) and the install runs exactly as before.

Changed

  • Uniqueness (user email, connector/session/invite tokens, resource hostname, recording keys, audit sequence) is now scoped per tenant instead of globally. In single-tenant use this is equivalent.
  • The internal per-install settings/config records (platform settings, SMTP, SSO, directory, branding, session policy, update check, audit-chain heads, cron heartbeats) are now keyed by tenant. The schema migration reshapes them in place, preserving all values — including the tamper-evidence audit-chain heads.

No data is moved or lost; row counts, the audit hash-chain, and behavior are unchanged. Verified against a copy of production before release.

v1.3.0

Tenant foundation (invisible groundwork)

This release lays the internal groundwork for a future multi-tenant hosted edition. It is invisible and behavior-preserving for the self-hosted product: multi-tenancy stays off (MULTI_TENANT unset), and the install runs exactly as before as a single implicit tenant.

Changed

  • Every table now carries a tenantId column (defaulting to default), with the schema migration seeding a single default tenant and backfilling existing rows to it. No data is moved or lost; row counts and behavior are unchanged.
  • The migration step now seeds the default tenant before applying the schema.

Nothing in the self-hosted admin console, login, sessions, or recordings changes. Row-level isolation and the multi-tenant runtime are deferred to later releases and remain off.

v1.2.1

Faster sign-in when Active Directory is connected

Fixed

  • Passkey / SSO sign-in no longer stalls on a slow directory. When AD/LDAP integration is enabled, each login checked the user's group membership against the directory before signing them in. That check had no time limit and ran on every login, so a slow directory made sign-in take several seconds. It now (1) times out after a few seconds and lets the login proceed (fail-open), and (2) is skipped when the user was already verified against the directory in the last few minutes — so most logins are instant again.

Two optional environment knobs: DIRECTORY_RESOLVE_TIMEOUT_MS (default 4000) and DIRECTORY_SYNC_THROTTLE_SECONDS (default 300).

v1.2.0

Org-wide clipboard policy

You can now set a default clipboard policy for the whole platform, so remote-desktop (RDP/SSH/VNC) and isolated-browser sessions can be locked down centrally instead of resource by resource.

Added

  • Policy → Default clipboard policy. A new tenant-wide setting (Admin → Policy) controls copy/paste for every resource left on Inherit: Allow, Block copy out, Block paste in, or Block both. Set it once to enforce a secure default (e.g. no copy-out) across all sessions; a resource can still override it.
  • Inherit option on resources. Each resource's Clipboard setting gains an Inherit (policy default) choice (now the default for new resources), so it follows the org-wide policy unless you deliberately override it.

Changed

  • Existing resources move to Inherit. Behavior is unchanged on upgrade — the default clipboard policy ships as Allow — until an admin tightens it.

Clipboard remains enforced server-side (guacd for gateway, KasmVNC for isolated); this release only adds where the policy is decided.

Captivo Access changelog