DigitalFrontier Shared Services
Always-on managed services — PostgreSQL, Cache, Storage, Registry, and an analytical database — shared across tenants with strict ACL isolation. No dedicated instance per project; one resilient service per tier, multi-tenant by design.
DigitalFrontier Shared Services introduces a new deployment primitive: always-on platform services that are shared across tenants, with access control enforced at the ACL layer rather than through physical isolation.
Instead of spinning up a dedicated database or cache per project — wasteful, expensive, and operationally heavy — a single highly-available instance of each service is provisioned per region. Tenants are isolated by ACL: each project gets its own credentials, namespace, and policy boundary, but shares the underlying compute and storage with others on the same infrastructure tier.
DigitalFrontier PG — a managed PostgreSQL service. Tenants receive their own logical database within a shared cluster. Connection pooling, automated backups, point-in-time recovery, and read replicas are handled at the platform level. Schema and data are strictly ACL-isolated.
DigitalFrontier RPG — a PostgreSQL proxy and gateway layer that handles connection multiplexing, query routing, and access policy enforcement in front of PG. Enables fine-grained per-tenant connection limits and audit logging without changes to application code.
DigitalFrontier Cache — a managed Redis-compatible cache. Tenants operate in isolated keyspaces with per-tenant eviction policies, TTL defaults, and memory quotas. Ideal for session state, ephemeral queues, and hot data tiers.
DigitalFrontier Storage — S3-compatible object storage with per-tenant bucket isolation and ACL-enforced cross-tenant access policies. Backed by distributed storage across the provider network.
DigitalFrontier Registry — a shared OCI-compliant container image registry with per-project namespaces, role-based push/pull permissions, and automated vulnerability scanning on push.
DigitalFrontier ADB — a shared analytical database optimised for OLAP workloads. Tenants submit queries against their own isolated dataset; the underlying columnar engine is shared. Designed for workloads that are too large for OLTP but do not justify a dedicated data warehouse.
Forward-looking: roadmap items describe work in progress or planned. Dates are estimates, not commitments, and scope may change as we learn.