Security by architecture.
Roster runs inside your infrastructure and resolves against the directories you already trust.
Directory data, platform configuration and operational records remain in the systems you control. Roster does not replicate them to an Advantys-operated cloud.
Self-hostedNo usage telemetryCustomer-managed credentialsLocal license verification
The model in one line
Roster is self-hosted and does not phone home.
It reads selected directory data, resolves who should act using the model provider you configure, and stores the resulting operational data inside your deployment.
There is no Roster-operated cloud holding your directory records, resolution history or configuration. When you select an external model provider, data sent to that provider is governed by your configuration and agreement with that provider.
Data residency & isolation
Choose the deployment shape that matches your infrastructure — Roster keeps its data where you put it.
Self-hosted, always
Run Roster as a standalone container with embedded SQLite or deploy Roster Enterprise across multiple instances backed by PostgreSQL. On-premises, private cloud or public-cloud account — your choice, your infrastructure.
Your data stays under your control
With SQLite, Roster data lives in durable /data storage attached to your deployment. Enterprise deployments can store application data in PostgreSQL infrastructure controlled by your organization. Nothing is replicated to an Advantys-operated data service.
No phone-home
Roster does not transmit usage telemetry, directory data or resolution history back to Advantys. License capacity is counted locally. Paid license keys are verified locally using the trusted public keyring in the production image.
Air-gap capable
Roster can run without public internet access when the required directory, identity, database and model endpoints are available inside the controlled environment.
How Roster handles directory data
Minimal collection, targeted synchronization, encrypted secrets — the connector layer is built for least-data.
Read-only at the source
Connectors for Microsoft Entra ID, Okta, Google Workspace, Workday, LDAP/LDAPS and CSV read directory data. Roster does not modify upstream accounts.
Minimal by default
Raw provider payloads are not stored. Roster retains only the canonical fields required for participant resolution — display name, primary email, source ID and explicitly allowlisted metadata.
Targeted synchronization
Scheduled refreshes update records already associated with Roster. They do not automatically materialize the complete source directory.
Encrypted connector secrets
Outbound provider credentials are stored encrypted using a deployment secret controlled by your organization.
Shared connector access in HA
High Availability rejects enabled local-file CSV connectors because instance-local files can diverge. Use S3 or SFTP so every Roster instance accesses the same connector content.
Authentication & access control
SSO through your IdP, scoped keys, and role-aware ownership — no shared admin accounts.
SSO through your identity provider
Human users authenticate through Microsoft Entra ID, Google, Okta, generic OAuth/OIDC or SAML.
Scoped, least-privilege keys
API keys carry explicit REST and MCP scopes. Effective access is the intersection of credential scopes, owner rights and resource rules — a scope cannot elevate an identity beyond its underlying permissions.
Authenticated by default
MCP access supports API keys, OAuth, or both. Production rejects an explicit unauthenticated MCP mode. A new production database requires a strong, deployment-specific bootstrap administrator password.
Roles and ownership
Administrators, project owners and members receive different responsibilities. Project owners manage their own projects, participants and delegations without platform-wide access.
Dedicated identities
Human users, AI agents and service accounts can use separate Roster identities with independently scoped and revocable credentials.
Audit & observability
Explainable history for every decision — attributable, retained on your terms.
Enterprise Audit Events
Durable audit events for authentication, credentials, identities, projects, participants, delegations, connectors and platform settings. Stable actor, resource, owner, effective-principal and credential identifiers make the history attributable.
Model-run observability
Every resolution captures its provider, model, token usage, cost and latency — no black-box decisions.
Controlled metadata
Administrators can minimize optional IP addresses, user agents and personal-looking metadata stored with operational records.
Configurable retention
Independent retention settings for Audit Events, Resolve Requests, Model Runs and worker journals — set the windows that match your policy.
OTLP telemetry export
Enterprise deployments can export traces, metrics and logs over OTLP to the observability stack you already operate. Telemetry is opt-in, customer-directed and never routed to Advantys.
System health dashboard
A built-in operations view surfaces readiness, worker activity, connector state and replication signals so your on-call team can verify the deployment without leaving Roster.
Privacy & data minimization
Field-level PII controls applied at write time — not just at display.
Minimize at write time
When retention of a field is disabled, new records do not store that field. The control is applied when the record is created — not only when it is shown.
Field-level PII controls
Choose which personal fields are retained in resolution results, stored response data, audit metadata, model diagnostics and worker journals.
Consistent response policy
The same field policy applies to stored resolution results and the corresponding platform, REST and MCP history responses.
Erasure support
Documented erasure procedures cover source records, stored responses, audit metadata, model diagnostics and worker journals for subject-deletion requests.
Durable identifiers
Audit history can preserve stable identifiers and security-relevant metadata without retaining unnecessary personal directory data.
Database security
SQLite for standalone, PostgreSQL for Enterprise — with role separation and connection controls.
SQLite for standalone
One Roster instance with durable /data storage. Create consistent online backups using the supported Roster SQLite backup process rather than copying live database and WAL files independently.
PostgreSQL for Enterprise
Enterprise deployments can use PostgreSQL with one or more Roster instances. Use the database provider's required TLS mode for every PostgreSQL connection.
Separate database roles
DML-only application role for Roster instances, and — when replicas are configured — a separate read-only role. Runtime roles never own the schema.
Connection controls
Each Roster instance maintains a separate connection pool for the PostgreSQL writer and every configured replica. Sized against the database service's connection limits.
High availability
Roster High Availability has two independent layers behind a common configuration.
- Two or more identical Roster instances behind a load balancer
- PostgreSQL with a writable primary and at least one read replica
Every Roster instance uses the same public authentication URL, authentication secret, provider-encryption secret, database endpoints, runtime configuration and Enterprise license.
Health-based routing
Use /health/ready for load-balancer routing — it succeeds only when configuration is valid, the PostgreSQL writer is reachable and connectors are HA-safe. /health/live covers process liveness. Both probes are unauthenticated, sanitized and excluded from rate limiting.
Primary consistency
Writes, transactions, readiness checks, authentication data and security decisions stay on the PostgreSQL primary. If the primary is unavailable, these operations fail closed until the writer endpoint is restored.
Read-replica routing
Roster distributes eligible ordinary reads across configured replicas. Replica reads are eventually consistent — monitor replication lag through your PostgreSQL service.
Shared runtime coordination
PostgreSQL stores shared rate-limit counters and worker coordination. Workers use leases, heartbeats, fencing tokens and bounded retries so work can be reclaimed after an instance failure.
Infrastructure boundary
- Load-balancer redundancy
- PostgreSQL replication
- Failure detection
- Primary promotion
- Stable writer and read-only endpoints
- Backups and point-in-time recovery
- Replica health and replication-lag monitoring
Roster validates HA mode uses PostgreSQL and required configuration, but does not operate or independently verify the cluster topology.
Compliance & operations
Roster slots into the security, retention and residency controls you already operate — plus a documented backup and recovery path.
Your governance, your environment
Because Roster runs in your infrastructure and under your identity provider, it can operate within the security, retention and data-residency controls you already maintain.
SOC 2
Roster is pursuing SOC 2 certification to address Enterprise customer requirements. If SOC 2 is required by your procurement process, talk to us about current scope, status and timing.
You control the perimeter
Terminate TLS at your load balancer, ingress or reverse proxy. Preserve the public host and scheme through forwarding headers. Store secrets in your deployment secret manager — never in source control or a custom image.
Bring your own model
Roster uses the model provider and credentials you configure — OpenAI, Anthropic, Mistral or a compatible approved gateway. The provider remains responsible for its own processing, security and billing.
Backups & recovery
SQLite uses Roster's online backup process. PostgreSQL uses the provider's backup plus point-in-time recovery when supported. A database backup does not necessarily include connector files or worker journals — protect every storage location required to recover.
Test isolated restores
Restore backups into an isolated SQLite or PostgreSQL environment on a regular schedule. After a PostgreSQL restore, start one Roster instance first and verify readiness, login, worker processing and connector access before returning to normal capacity.
Built by Advantys, makers of WorkflowGen — process automation trusted in production since 2003.
Reporting a vulnerability
Found a potential security issue? Email security@advantys.com. We welcome responsible disclosure and will acknowledge your report.