↓ Skip to main content
fremverk

Reference platform

A concise overview of the EU-sovereign platform shape fremverk typically helps teams design and deliver

Table of Contents

What this page is
#

This is the concise version of the target platform shape we typically help customers design and deliver. It is not a one-size-fits-all blueprint, but it follows the baseline in our architecture notes: one T Cloud account by default, enterprise projects as the main boundary, and a shared platform foundation that is extended only where the design justifies it.

Core structure
#

  • Boundary model — One T Cloud account by default, with enterprise projects as the main permission, ownership, and cost boundary.
  • Required platform projects — platform-management for shared platform operations and platform-connectivity for shared routing, DNS, edge, and perimeter controls.
  • Conditional platform projects — platform-identity only when a self-hosted identity layer such as Authentik is actually required, and platform-security only when security tooling or retention boundaries justify it.
  • Delivery path — Platform and workload resources defined through Git, OpenTofu, CI/CD, and policy checks so the operating model stays declarative and reviewable.

Shared platform services
#

  • Networking and DNS — platform-connectivity owns shared routing patterns, shared DNS zones, hybrid connectivity, and perimeter controls by default.
  • Ingress and edge controls — Shared edge is for genuinely shared platform services. Public-facing workloads normally own their own public edge in their own project, with WAF for public HTTP and HTTPS ingress.
  • Runtime baseline — PaaS-first in platform-management with OBS, CES/LTS, SMN, CTS, FunctionGraph, and SWR. Git and CI/CD are consumed from Fremforge at frem.sh, so no shared container platform is required at bootstrap.
  • Automation-first runtime choice — FunctionGraph-first for lightweight automation and event-driven jobs. Kubernetes, managed services, or virtual machines are added when the workload or service actually needs them.

Security and control layer
#

  • Policy and governance — Guardrails, least-privilege access, tagging, and compliance-oriented checks are built into the baseline instead of added later.
  • Identity and access — Human access is federated from the enterprise identity provider by default, with local break-glass access retained and automation scoped through agencies.
  • Keys, secrets, and auditability — Managed key and secret services are the primary source of truth for keys and platform secrets, while API-level audit trails provide auditability and traceability.
  • Backup and recovery — Backup coverage, retention, restore paths, and rebuild-from-code expectations are defined for shared services and critical workloads.

Operating model
#

  • Observability baseline — Metrics, logs, alerts, notifications, and audit trails form the baseline monitoring and audit stack, with platform alerts for ingress, Fremforge tenant reachability, backups, and key dependencies.
  • Runbooks and handover — Practical operational procedures so the platform can be owned after delivery.
  • Hybrid transition — Space for existing identity, networks, and business systems to remain in place while the target state is built out.
  • Team enablement — Delivery designed so the customer team becomes more capable as the platform matures.

What usually changes first
#

The first useful step is rarely “move everything.” It is usually one or more of these:

  • A clearer enterprise-project and governance baseline
  • A more defensible delivery path for source code and CI/CD
  • Better identity and access boundaries
  • A first sovereign workload platform with monitoring, backup, and perimeter controls built in
  • A migration path for the workloads that matter most

Where to go next
#

If you want the practical buyer questions answered first, read the FAQ.

If you want to discuss how this maps to your current estate, get in touch.