An offline license
A signed license is verified before any of its contents are read. No license server, no phone-home.
[ Deployment ]
Any cloud, or air-gapped.
Tabellix runs on Kubernetes with no dependency on a cloud provider. You bring standard infrastructure, the license is verified offline, and the software never calls home.
01 Where it runs
Your cluster, your network.
The core has no dependency on any cloud provider. It runs on Kubernetes in a public cloud, in your own data center, or on a network with no connection to the internet.
| Shape | What it is |
|---|---|
| Dedicated deployment | The default: one company per namespace, with its own api and worker roles, database, keys, storage, and ledger. |
| Embedded in your product | A dedicated deployment behind your product's gateway, with security events sent to your collector and your brand on every customer-visible surface. |
| Many companies, one operator | An operator provisions and maintains a dedicated set of database, keys, storage, and ledger for each company. |
| Air-gapped | License checks, release verification, and record verification need no network. |
Deployment guides
- Red Hat OpenShift, strict SCC
- Amazon EKS
- Azure AKS
- Google GKE
02 What you supply
Standard parts, no lock-in.
Tabellix runs on infrastructure your team already operates. Each prerequisite is an open standard or a common service.
| Prerequisite | What it is for |
|---|---|
| Kubernetes | The api and worker roles, helpers, and installation checks. Every workload meets the Pod Security restricted standard. |
| PostgreSQL | Metadata, records, the ledger, and durable jobs. Synchronous replication and a connection pooler are supported. |
| An object store | Encrypted content, viewing copies, and sealed checkpoints. Any S3-compatible store, Azure Blob Storage, or Google Cloud Storage, with or without object lock. |
| A key service | OpenBao, one per deployment or a namespace of a shared instance. It holds keys the database cannot use. |
| A time-stamping authority | An RFC 3161 authority that stamps each signed checkpoint. No write waits for it. |
| An identity provider | Any OIDC provider for sign-in. SCIM 2.0 to provision people and map directory groups to roles. |
| A malware scanner | Any clamd, or any ICAP service (RFC 3507). Nothing is served until the scanner answers clean. |
| Optional services | Text extraction for search, a document converter for full-fidelity Office viewing copies, an SMTP relay, an OpenTelemetry collector, and NATS JetStream. |
03 Offline trust
Nothing phones home.
A license, a release, and a record can each be checked with no network. Tabellix never calls home, so it is built to run the same on a closed network as in the cloud.
01
02
Reading never stops
A license warns from 60 days before it expires and allows 30 days of grace. It never blocks reading or exporting existing records.
03
Release verification offline
The release verification mechanism runs entirely offline, against a key fingerprint you type in.
04
SBOMs with every image
CycloneDX and SPDX bills of materials, signed and bound to the image digest. Images are scanned for vulnerabilities.
05
Minimal images
Each image is one static binary on an empty base, running as a numeric user with a read-only root file system.
06
Records verified offline
Disclosure bundles, exports, and period evidence are verified on a laptop with no network and no database.
04 Installation qualification
Every installation qualifies itself.
36 installation checks qualify each deployment. Most of them run read-only in every pod, and an operator tool adds the rest. The results feed the IQ protocol and report that Tabellix generates for your validation.
01
Checked in every pod
Most checks run read-only inside every pod of the installation. One of them confirms, live, that every workload meets the Pod Security restricted standard.
02
Checked from outside
An operator tool adds the release bundle, the running images, the installed chart, the live objects, and a network policy probe.
03
Generated IQ and OQ
IQ and OQ protocols and reports, the traceability matrix, and a validation plan and PQ templates are generated from the model, the catalog, and the tests.
04
Live evidence
An evidence endpoint reports live control state, the profile hash, transport, backups, the last recovery drill, the store lock level, and the license.
05 Object store
Any store, with the lock it really has.
One storage port serves every supported store, and each adapter passes the same conformance suite. Tabellix reports the lock level the store actually enforces, and never assumes one.
| Lock level | What the store does | What Tabellix does |
|---|---|---|
| Object | Each object is written locked until its retention ends, in compliance or governance mode chosen per deployment. | Retention extends only upward, and legal holds extend the store lock. |
| Bucket | The bucket enforces a retention rule. | Reports the bucket lock in evidence and in the IQ and OQ tables. |
| None | The store keeps what it is given. | Enforces retention in the application, and the ledger detects any tampering. |
01
Adapters
Any S3-compatible store with Object Lock, and native Azure Blob Storage and Google Cloud Storage.
02
Every store, inventoried
An offline, read-only inventory lists every store of a deployment with what its owner needs to delete it and the evidence to keep.
06 Reliability and scale
Failure is specified, not assumed.
Tabellix specifies 448 failure modes, from dependency outages and partial writes to leader changes and clock skew, each with defined behavior. When something fails, the answer is precise.
01
High availability
PostgreSQL with synchronous replication behind a connection pooler. The api and worker roles scale horizontally with autoscaling.
02
Outages answered precisely
A missing dependency returns 503 with a reason and Retry-After. Readiness reflects the dependencies each role needs, and policy errors fail closed.
03
Durable jobs
Jobs live in PostgreSQL with leases, heartbeats, fencing, and retries with backoff. Terminal failures are audited.
04
No session-held locks
Every periodic duty runs under a lease with a term and a fence, so it works behind a transaction pooler.
05
Fair across companies
Shared helpers and request slots are scheduled fairly per company, with per-company caps.
06
Observable
Metrics with latency histograms on every role, structured JSON logs, request ids, and a security event stream over OTLP.
07 Backup and recovery
Restore, then prove it.
A restore is not done when the database starts. A restored deployment starts in recovery mode and passes a verification gate before it serves.
backupsrestoredinto a fresh stack
recovery modeshreds replayeddestroyed stays destroyed
gateverifiedagainst sealed history
reportwhat was lostnew ledger epoch, signed
01
Separate backups
Database WAL and base backups go to a separate backups bucket under separate credentials.
02
Destruction survives a restore
Records of destroyed content are copied with the backups and replayed on every restore, so a restore never brings destroyed content back.
03
A restore is a proven prefix
A database restored behind a sealed checkpoint continues the ledger in a new epoch, with a signed record of what was lost.
04
Recovery drills
A drill measures recovery point and recovery time and writes a signed report.
05
Key lifecycle
Keys rotate, with rewrap records and a minimum decryption version.
06
Integrity monitoring
Stored content is re-verified on a schedule. Damaged content is marked, never served again, and repaired from locked versions where they exist.
08 Install, upgrade, configure
Changes you can see.
Installs and upgrades run from Helm charts or plain manifests. Configuration below the deployment changes through approved releases, live without a restart.
01
Charts and manifests
Custom resources, the core chart, a policy chart for admission control, network policies for every helper, reference values per platform, and a values schema with guards.
02
Default-deny network
Network policies deny by default with an allow per workload. Admission constraints refuse root containers, added capabilities, host ports, and host processes.
03
Encrypted links
Optional in-process TLS 1.2 and 1.3, including hybrid post-quantum key exchange, or a declared service mesh. Certificates rotate without a restart.
04
Upgrades and rollback
An upgrade test starts from the previous release and verifies the sealed history across versions. Rolls are refused when the new pods would not fit the quota.
05
The deployment profile
Settings fixed at installation live in a read-only profile. Its hash is recorded at every start, so any change to it is visible.
06
Configuration releases
Everything an administrator may change ships as a release, reviewed as a diff, approved by the distinct approvers the profile requires (never the author), and loaded by every process in seconds.
Set in the deployment profile
- Access logging mode
- Store lock mode and floor
- Minimum retention
- Early destruction
- Signature sign-in age
- Share limits
- Break-glass
- Number of approvers
- Agent preset
- Languages
- Time-stamping authority
- Upload limits
- Identity issuers
- Branding
09 FAQ
Deployment questions.
01Where does Tabellix run?
On Kubernetes, in a cloud or on premises, and designed for air-gapped networks. The core has no dependency on a cloud provider, and deployment guides exist for OpenShift, EKS, AKS, and GKE.
02What do we need to provide?
Kubernetes, PostgreSQL, an object store (any S3-compatible store, Azure Blob Storage, or Google Cloud Storage), an OpenBao key service, an RFC 3161 time-stamping authority, an OIDC identity provider, and a malware scanner that speaks clamd or ICAP. Text extraction, a document converter, mail, and an OpenTelemetry collector are optional.
03Does Tabellix need internet access?
No. The license is verified offline, release verification runs offline, and the software never calls home.
04Do we need an object store with object lock?
No. With object lock, content is written locked until its retention ends. Without it, retention is enforced by the application and the ledger detects tampering. Tabellix reports the lock level the store actually enforces.
05How do we qualify an installation?
36 installation checks run in every pod and from an operator tool, and their results feed the IQ protocol and report that Tabellix generates for your validation.
06What happens if a license expires?
A license warns from 60 days before it expires and allows 30 days of grace. It never blocks reading or exporting existing records.
07How is a restore verified?
A restored deployment starts in recovery mode, replays the record of destroyed content, and passes a verification gate against the sealed history before it serves. It reports what was lost.
[ Contact ]
Plan your deployment.
Tell us where it has to run and who qualifies it. We will walk through the prerequisites and the installation checks with your platform team.