A shared deployment and operations foundation#
SK.Infrastructure supplies application-neutral identity, certificate, ingress and optional data-service capabilities. Consumers retain their own domain model, application data, runtime, UI and permission enforcement. A consumer does not need an Infrastructure project or package reference in its application build; the boundary is the reviewed identity, network, trust and service contract.
The documented complete Docker foundation contains six services:
| Service | Responsibility |
|---|---|
| Smallstep CA | Private certificate identity and issuance machinery |
| Traefik | Reviewed application ingress and TLS routing |
| Keycloak | Shared identity-provider runtime and approved registration |
| PostgreSQL | Durable databases with separate application allocations |
| RabbitMQ | Scoped broker transport, queues and delivery policies |
| Redis | Optional bounded cache service with application-specific access |
The fresh complete profile gives Keycloak its own database, schema and login in the common PostgreSQL service. Application allocations are separate. Reuse installed services when their topology and capacity fit the requirement; evaluate another instance explicitly when isolation, capacity or availability requirements demand it.
Application profiles preserve ownership#
An application profile declares its realm reference, clients, role contract, hosts, ingress and optional theme or explicit seed inputs. Foundation code remains application-neutral. Adding an application should not require application-name conditionals in the shared runtime.
A realm is an explicit SSO/security boundary, not automatically one realm per application. Profiles can share it only when their settings agree and ownership does not collide. Prefer explicitly scoped application roles and exact callback/origin registrations. Keep any legacy role contract visible rather than silently granting it to new applications.
The profile compiler validates ownership, hosts, callbacks and network reservations. A generated handoff describes public settings and separately protected credential references. It is not a universal configuration section automatically understood by every application. The consuming owner maps those values to its chosen host configuration.
Network and trust boundaries#
Web ingress, the application backend and shared data capabilities have distinct network roles. Only the intended frontend joins its ingress network. APIs, workers and databases are not exposed merely because the frontend is public. Applications join only the shared capability networks they require.
Canonical endpoint names must match certificate identities. Data clients verify the CA chain, hostname and expiry; PostgreSQL production connections use SSL Mode=VerifyFull. A DNS record alone does not make a Docker-only service reachable. The shared-services profile publishes no data-service host ports, including management ports.
| Resource | Application boundary |
|---|---|
| PostgreSQL | Separate database/schema ownership and reviewed runtime table grants |
| RabbitMQ | Producer-owned exchanges, subscriber-owned queues and exact routing permissions |
| Redis | Registered application key prefix, approved commands and declared TTL/value budget |
| Certificates | Public trust distributed to consumers; signing keys remain with the infrastructure owner |
Broker transport does not implement an application's transactional outbox. Redis access controls do not establish per-user memory quotas or enforce every TTL/value-size rule. Consumers remain responsible for the behavior declared in their service contract.
Choose the correct installation lifecycle#
The v1 complete installation contract targets a new Linux Docker namespace with empty state. It validates the reviewed target, generates protected service inputs and records installation verification. It is not a migration command for populated services.
The newer v2 managed path composes the foundation as a Portainer-managed stack and exports generic topology, DNS and trust information. Its documentation identifies it as a staging candidate with separate production qualification and maintenance gates. Selecting a production environment in a wizard is not itself production acceptance. Do not substitute a v1 partial-stack maintenance command for the v2 managed composition.
An existing installation requires an additive, reviewed operation preserving identity, certificates, storage and allocations. Removing a profile is not permission to delete populated resources. Initial setup, application enrollment, application migration and application release remain different steps.
The documented baseline is a single-host topology, not an HA or measured workload-capacity guarantee. Validate placement, resource budgets and failure domains for the intended installation. See deployment flow and operations and recovery.