Self-hosted deployment and availability

Current availability

Kastra’s hosted service is available today. The self-hosted enterprise appliance is in development, not generally available. The next milestone is an assisted pilot: one frozen release, one qualified host configuration, one client workflow, and a complete acceptance campaign.

Development candidates already implement signed installation, offline licensing, owner administration, SMTP, backup and recovery activation, retained-content custody, durable proxy execution accounting, and an assisted upgrade path. Customer qualification, final release trust and delivery, operating terms, and handoff remain open. There is no public self-service appliance release to install today.

Contact Kastra with your network, identity, model, evidence, and operating requirements. Confirm the supported scope and acceptance criteria before planning a production installation. A working demonstration does not establish a supported air-gapped deployment.

Implemented in development builds

Area	Appliance behavior
Ownership	One workspace per installation; initial owner bootstrap or reuse of the existing sole workspace
Accounts	Configurable public signup, validated invitation signup, and workspace member administration
Licensing	Locally verified signed license bound to the installation, with a 30-day evaluation and explicit lifecycle status
Console	Owner Deployment settings, license/revocation uploads, SMTP administration and test email, redacted support export, access links, and license guidance
Notifications	Encrypted SMTP settings, verified STARTTLS or implicit TLS, invitation and single-use password-recovery flows
Private dependencies	Explicit model endpoints and scoped CA trust; operator-approved webhook origins, ports and resolved addresses
Installation and evidence	Source-free installation from authenticated payloads, pinned offline images, migration/bootstrap, encrypted backups and offline decision/execution verification
Recovery	Source fencing, paused restore, current access/MFA recovery, credential quarantine and explicit activation with preserved history
Retained content	Metadata-only, masked or encrypted-original history, expiry and independently retained erasure custody checked during recovery
Proxy execution	An opt-in, bounded non-streaming workflow with durable admission, dispatch/outcome records, once-only operation accounting and explicit uncertain outcomes
Assisted upgrades	A fenced source, final backup and fresh replacement; only qualified source/target pairs, with downtime and induced-failure recovery
SSO recovery	Configured login remains available to existing active members; new JIT memberships require the SSO entitlement
Runtime governance	License expiry preserves active policy evaluation, approval/resume, and decision recording
Approval capacity	Persistent workspace/environment backlog ceilings, explicit overflow refusals and access to existing pending retries

Development acceptance includes native arm64 source-free installation, separate-host recovery/MFA, SMTP rejection and recovery, concurrent approval resumes, process interruption, older-backup erasure custody, and an exact source/target datastore upgrade. These results apply to the tested candidates and engineering profiles. They do not qualify every architecture, customer network, client or later build. Native amd64 customer qualification, if selected, remains open.

Ownership and signup

A fresh appliance needs bootstrap administrator credentials. Startup refuses an empty unconfigured, ambiguous, or unreadable workspace inventory. An existing single workspace is reused by ID; changing bootstrap credentials does not reset an existing password.

Workspace creation and deletion are locked after bootstrap. Membership and role management remain available. Only an authenticated OWNER of the installation’s workspace can replace its license.

For invitation-only installations, public signup is disabled on the server. The console follows the advertised signup setting; a valid invitation still permits registration. Preserve a tested local OWNER recovery account even when SAML is the primary login method.

License lifecycle and renewal

License verification runs locally against trusted public keys and does not contact Kastra. The license is bound to the installation’s stable instance ID. Evaluation lasts 30 days; the deployment summary reports evaluation, validity, approaching expiry, grace, expiry, or invalid-license state, together with the effective plan and whether authoring is degraded.

An invalid license can coexist with an active evaluation. Read the effective status instead of treating every invalid-license banner as a loss of service. After evaluation or license grace ends, authoring and licensed configuration/provisioning become limited.

Self-hosted license expiry does not switch runtime governance to observe-only. Existing policy evaluation, HOLD/approval/resume, and decision recording continue. Policy denials, safety limits, and operational failures still apply. The hosted subscription model has different lapse behavior.

A signed license cannot change the runtime prompt or tool-input byte ceilings. This keeps accepted input sizes consistent through the license lifecycle.

For an agreed appliance deployment, an owner can use PUT /api/v1/deployment/license with the installation workspace selected through X-Organization-ID. The complete request body is limited to 64 KiB; oversized bodies return HTTP 413 without replacing the stored license. Development builds also provide an owner-only upload interface in Deployment settings.

A trusted renewal can also be imported at server startup through KASTRA_LICENSE_PATH or KASTRA_LICENSE, configured individually. Keep the existing database and instance identity; creating a new instance is not a renewal procedure. Never place a private signing key in the appliance.

Kastra-operated license issue, renewal and revocation tooling is implemented. The production license-signing public key is embedded, and an installation has exercised issuance, revocation and relicensing. This license trust root is separate from the signature authenticating an appliance release. Development release signatures do not establish production release trust; the final customer download, trust handoff and license lifecycle must still be accepted for the selected release.

A disconnected installation receives revocations through explicitly imported signed data. Offline verification does not provide immediate remote revocation. Private signing keys remain outside the appliance.

SSO and email recovery

An already-configured, enabled SAML IdP remains usable by existing active members in every license state, including a valid downgrade without SSO. Signature/assertion validation, request correlation, and disabled-IdP checks remain active. Deactivated members remain blocked.

New just-in-time memberships require configured JIT and the current SSO entitlement. Missing or unreadable entitlement/membership state does not authorize new provisioning. SSO configuration changes remain entitlement-gated. Test your real IdP, owner recovery, renewal, and user deactivation before handoff. SAML and SCIM guide.

Development builds let the owner configure a TLS-verified SMTP relay, store credentials encrypted at rest and send a test email. Invitation and password-recovery delivery have passed isolated relay tests, including wrong-CA, wrong-hostname and missing-STARTTLS failures. A configuration indicator alone does not establish delivery: verify the actual relay, invitation and recovery paths in each installation. The console/log email provider used by some demonstrations does not deliver messages.

Invitation creation reports email_accepted separately from creating the pending invitation. A failed submission preserves the invitation for resend after relay correction. Sender acceptance is not proof of inbox delivery. Recovery quarantines email delivery until the owner confirms the current relay and supplies fresh credentials.

Pending approval capacity

Development appliances default to 10,000 pending approvals per workspace and 1,000 per environment. Operators can set positive limits up to 1,000,000, with the environment limit no greater than the workspace limit. These resource limits are independent of the license. Explicit configuration requires a signed release that advertises support for this control.

At capacity, new approval requests receive a visible resource refusal. Existing pending retries retain their original checkpoint; resolving an approval releases its slot. A row counts until its stored status changes, including while it awaits an expiry sweep. Lowering a limit does not delete approval history. Limits persist across server restarts and encrypted backup/paused restore.

The defaults are admission ceilings, not throughput or storage-sizing guarantees. Size the installation for its request volume, review latency, retained evidence and recovery requirements. The caller must still follow its heartbeat and expiry protocol; a capacity limit does not keep an abandoned request alive.

Network boundary and clients

Offline license verification is one component of a disconnected deployment. Inventory the browser, identity provider, model endpoint, notifications, storage/export, monitoring, downloads, and updates. Prompts sent to an external model still leave the environment through that provider path.

Appliance console builds suppress hosted analytics, Sentry, and Turnstile, including when deployment discovery fails. This is not proof that every component has no egress. Whole-appliance and browser disconnection must be tested against the proposed configuration.

Webhook configuration can be restricted by an immutable operator policy listing exact HTTPS origins, ports, approved IP addresses/ranges and optional per-receiver CA certificates. Admission and delivery both check resolved addresses; redirects, ambient proxies and metadata/local-service destinations are refused. The policy travels with authenticated backup custody and cannot be silently widened during paused restore. Without an operator policy, webhook destinations retain the public-only default. These application checks complement the installation’s firewall and do not prove its entire network boundary.

Model trust is configured separately from webhook and SMTP trust. Private endpoint support must be validated against the actual model provider and supported client workflows, including streaming and approvals where required.

The hosted product, Edge, local MCP gateway, and operator CLI are distinct from a complete appliance. Linux Edge archives are released, and a local gateway calls the configured Kastra service. Set the API deployment root and customer console URL before login on a private deployment. Client availability does not certify disconnected operation: login, links, trust, update behavior and version compatibility still require deployment-specific validation. Platform support · Authentication.

Recovery, execution and upgrades

Establish the release public-key fingerprint and verifier checksum through an independent trusted channel. A bundle’s own key is not independent proof of its authenticity. Development packaging authenticates the manifest, file inventory and offline images before installation.

Restore begins paused. Activation requires reconciled current access, source fencing, execution state and evidence custody. A successful database restore alone does not make the replacement safe to serve. Preserve current erasure custody independently of database backups: an old database and an old custody copy together cannot prove that later-erased content stays unavailable. Original access requires the current OWNER, fresh MFA and an audited purpose. See retention and recovery.

The assisted pilot’s execution journal covers one bounded non-streaming proxy workflow with console approval. The client must preserve a canonical operation UUID and identical request bytes on resume. Uncertain dispatch/outcome state requires attributed reconciliation; it is not permission to retry automatically. These controls do not promise exactly-once effects in every external system, streaming path or tool adapter. See proxy approvals.

Assisted upgrade preparation permanently fences the source before its final backup and migrates a fresh paused replacement. A changed datastore is accepted only through the release’s signed, exact-source compatibility contract. The tested upgrade pair and its process-interruption, low-space and migration-failure controls are engineering evidence, not an arbitrary-version upgrade promise. Plan a maintenance window; do not roll back by restarting the fenced source or an old image against a migrated database.

Roadmap to customer handoff

Next step	Required result
Qualify the customer profile	Named client/version, model, Linux host/architecture, Docker/Compose/image store, storage, SMTP, TLS/network boundary and independent custody; measured capacity and accepted failure behavior
Complete release and support inputs	Independently trusted signed download, current exact-artifact vulnerability review, dependency inventory/notices, agreed terms, support and patch owners, demonstrated manual reporting and license renewal
Run the final acceptance campaign	The same signed bytes pass install/identity, governance/approval/accounting, backup/restore/custody, the supported upgrade pair and induced failures, license/network/capacity, and a new operator’s handoff exercise

Broader platform and upgrade matrices, high availability, automatic update discovery, fleet operations, signed usage-report automation, and additional clients are later work unless the selected pilot requires them. No completion date is promised. A public Helm installer, Kubernetes operator, customer-KMS evidence integration and universal air-gap support are outside the current supported scope.

Agree on the operating contract

Responsibility	Evidence to establish before handoff
Installation and upgrade	Supported versioned package, dependency inventory, migration sequence, and failed-upgrade recovery
Identity and custody	Bootstrap owner, local recovery login, real IdP test, key custody and rotation
Network and model access	Observed disconnected behavior and an approved list of external dependencies
Approval delivery	Real-client compatibility, requester/approver identity, restart behavior and duplicate/reordered events
Evidence and recovery	Export/verification scope, backup scope, retained keys, and a restore drill on a clean environment
Capacity and support	Workload/backlog limits, operating ownership, incident handling and supported update process
Commercial scope	Approved license, seat allowance, permitted features, price and contractual terms

These acceptance checks remain required before a customer-operated installation. Pilot evaluation · Operations · Enterprise discussion.