How we run your instance

We run RealmSSO for you. This page says how we run it today, and it says plainly what we do not have yet. Terms such as realm are in the glossary.

How current these facts are

We apply host and cluster changes by hand. A record on file does not prove that a change is live. So each fact below carries the date we last saw it. Where a fact has no date, it comes from our deployment records, which we read on 2026-10-03.

Where it runs

You do not install or operate anything. We deploy and upgrade RealmSSO ourselves.

All hosted accounts share one RealmSSO instance and one sign-in service. They run on one production cluster that we operate. There is no instance for each customer and no choice of region.

Today the cluster is one machine. It has no second node, no standby and no second region.

The machine runs one API server, one sign-in service, two copies of the dashboard and one Redis cache. It also runs two PostgreSQL 16 databases. One database is for RealmSSO. The other is for the sign-in service.

Production runs a pinned release, named by date and commit. A release changes only when we deploy it by hand.

How your account is kept apart

Every account gets its own realm in the sign-in service. A realm is a separate sign-in space. It has its own users, clients, identity provider (IdP) links and signing keys. RealmSSO creates the realm in the same request that creates the account.

Between realms, one account's tokens, sessions and IdP links do not work for another account. The realm name comes from the account id, not from the customer name. Accounts and isolation explains the design.

Everything below the realm is shared. Accounts share the sign-in service process and its database. They also share the RealmSSO database, one cache, one machine and one encryption key ring. The isolation is logical, not physical.

One realm for each account is the design. Nothing in the database forces it. At start-up and every five minutes, the server checks that no realm holds two accounts. It writes an audit row if one does. The check reports a problem after it happens.

RealmSSO creates each new realm with self-registration off, password reset off, brute-force protection on and event recording on. These settings apply to direct sign-ins in the realm. A user who signs in through a connection signs in at the identity provider of the customer.

No production customer has used a realm yet.

The API server and the sign-in service run as non-root users. They drop all Linux capabilities and use the default seccomp profile. They hold no cluster API token. The namespace uses a default-deny network policy. It allows DNS, its own databases, incoming traffic, health probes and traffic to public addresses.

RealmSSO and the sign-in service each have their own database instance. The RealmSSO runtime role cannot change the database schema. A separate role runs schema changes.

The code can give each account its own sign-in hostname. This feature is switched off in production. A hostname would be a nicer address, not a boundary. A binding at the edge would make it a boundary. We built nothing for that binding. Building now.

Security overview covers access control and the audit log.

Your data: encryption, keys and backups

RealmSSO encrypts two database fields with AES-256-GCM. They are a connection's OIDC client secret and its SAML signing certificate. We make no claim about disk encryption or backup encryption.

API keys, SCIM tokens, sign-in links, invite links and refresh tokens are stored only as SHA-256 hashes. Webhook signing secrets are stored readable, because the server needs the key itself to sign each delivery. See Encryption and secrets.

The encryption keys sit in the platform's secret store. There is no key management service, no hardware security module and no customer-managed key. One key ring serves all accounts.

The key ring supports rotation. No rotation has run in production. The key ring has no copy off the machine.

Every night we back up both databases, the cluster state, the host configuration and the cluster manifests. We keep the backups 30 days. We last verified the backup timer live on 2026-08-03.

The backups stay on the machine they protect. A restore returns the data as of the last nightly backup. There is no point-in-time recovery. We have not tested a restore with real data.

Backup, recovery and deletion gives the details. It also says what happens when you delete an account.

Network

Three public endpoints exist. api.realmsso.com serves the API. sso.realmsso.com serves the sign-in service. app.realmsso.com serves the dashboard.

Each public endpoint uses a Let's Encrypt certificate. TLS covers the public endpoints. We make no claim about encryption between our own services.

The API sends standard security headers and a one-year HSTS header on its responses. We measured this on 2026-10-03.

The host firewall drops inbound traffic by default. It allows web traffic from the internet on ports 80 and 443. Port 80 serves redirects and certificate checks. Other ports that the cluster or a container opens on the machine are not reachable from the internet. The databases listen only on an internal network. We applied the firewall and measured it from outside on 2026-08-04.

Apart from DNS, their own databases and each other, our workloads cannot reach private network ranges. Outbound traffic to public addresses is not restricted by destination.

When RealmSSO fetches a URL you give it, it checks on each call that the target is public. This covers SAML metadata, OIDC discovery and webhook endpoints. It follows no redirects, and it applies a timeout.

Two gaps remain in that check. A name can change its address between the check and the connection. The sign-in service also re-reads SAML metadata itself, outside this check.

The API limits each client address to 200 requests per window. It counts requests in the server's memory. We measured the limit on 2026-10-03. The API trusts exactly one proxy hop, so a client on the internet cannot choose the address that the limit counts. See Limits and capacity.

Changes and upgrades

We deploy and upgrade RealmSSO ourselves. Each deploy is manual. Each release is a pinned build. The previous build stays on the machine, so we can roll the code back.

Before we apply a release, we render the deployment and compare it with the running release. Database migrations run before the new version serves traffic. These steps are a manual practice, not an automated gate.

Schema changes are forward-only. We do not roll back the database changes of an upgrade.

The server refuses to start with a placeholder secret or a malformed key ring. If the sign-in service is down at start-up, the API still starts. Routes that do not use the sign-in service keep working.

Restarting or upgrading the sign-in service interrupts sign-in while it starts. We publish no upgrade schedule. We give no advance notice of maintenance.

Health, monitoring and incidents

We run no monitoring or alerting on the platform. There is no status page. Monitoring and health says what RealmSSO records about your account.

The API has a public readiness endpoint, /readyz. It checks the database and the cache. It reports the sign-in service for information only. It is not a status page.

The audit log records changes made through the RealmSSO API. Any viewer, member or admin of the account can read it. So can an API key with audit:read.

Audit writes are best effort. An action can succeed with no audit row. Nothing purges audit rows. They are deleted with the account.

Sign-ins through a connection reach RealmSSO as events about every 60 seconds. RealmSSO keeps them 90 days by default.

Incident response is ours. Contact support@realmsso.com. No response time, on-call rotation or status page exists.

Integrating with your instance

The REST API is under /api/v1. It accepts a 24-hour dashboard session or an API key. An API key belongs to one account and carries named scopes. See API overview.

RealmSSO serves SCIM 2.0 at /api/scim/v2. See SCIM directory sync.

Webhooks are signed with HMAC-SHA256. They are delivered from a durable queue. A delivery gets 3 attempts, then becomes a dead letter. RealmSSO keeps delivery records 90 days.

Delivery is at-least-once. A delivery can repeat after an interruption. Make your receiver ignore a delivery id that it already processed.

One event type exists today: connection.status.changed. RealmSSO records a dead letter and does not announce it. We do not promise a fixed source address for webhook calls. See Webhooks API.

What we do not have yet

Each line below is true today. We keep these in one list. Other gaps are stated in the sections above. What ships today shows the same list next to the capabilities that are live.

• RealmSSO runs on one machine today. There is no standby, no second region and no high availability.
• Nightly backups stay on the machine they protect. We do not yet copy them off it.
• The encryption key ring has no copy off the machine.
• We have not tested a restore with real data. The one drill, on 2026-08-02, ran over a database in which 19 of 20 tables were empty. The sign-in service’s database was never restored.
• A restore returns the data as of the last nightly backup. There is no point-in-time recovery. We publish no recovery-time or recovery-point figure.
• We run no monitoring or alerting on the platform, and there is no status page.
• A written agreement covers the Managed and Enterprise tiers. No service-level figures exist yet, and there is no uptime figure.
• We hold no SOC 2, ISO 27001 or other certification, and no third-party penetration test. An internal security review exists.
• RealmSSO has no production customers yet. No customer account has gone live on production.
• There is no dedicated instance, no private connectivity, no customer-managed keys and no choice of region.
• We publish no upgrade schedule and give no advance notice of maintenance. Restarting the sign-in service interrupts sign-in while it starts.
• The audit log has no export or streaming. There is no metrics endpoint, and application logs are not shipped to you.