What a platform is.

Before deciding where Portainer fits, you need a shared picture of what a container platform contains. "Container platform" gets used to mean whatever the vendor sells, which has made the term useless in a technical conversation. This module gives you the vocabulary the rest of the course uses.

A complete enterprise container platform spans seven layers, each carrying its own operational responsibility, integration cost, and risk: the operating system layer, the Kubernetes distribution layer, the platform management layer, the security and governance layer, the GitOps and configuration management layer, the observability and telemetry layer, and the developer and operator interaction layer.

You don't have to build all seven yourself - the market is full of products covering one or several. The point of the seven-layer picture is that it lets you say what any given product does and doesn't cover, and where the gaps are that you have to fill. Every platform decision is a decision about which layers you buy, which you build, and which you leave to someone else.

The bottom of the stack is the runtime. There are three shapes in an enterprise estate today, and most enterprises run all three, whether they meant to or not.

Docker Standalone runs single containers on a single host with no orchestration. It's what shipped first and what most developers still install locally. It's a fine, correct choice for single-instance stateful services, edge appliances, and industrial gateways.

Docker Swarm orchestrates containers across a cluster using Docker's own primitives. It's simpler than Kubernetes, with none of the CNCF sprawl, and remains legitimate for existing Swarm operators who value operational simplicity over ecosystem breadth. Nobody knows Swarm's long-term trajectory for certain - it may keep working well for years, or not - which is why Portainer built D2K: a way for Swarm shops to move onto Kubernetes without retooling their applications, for whenever that day comes.

Kubernetes is the default at scale in most enterprises: a much richer object model, bigger ecosystem, bigger operational surface. It isn't a runtime itself - containerd, CRI-O, or another OCI runtime sits underneath, and Kubernetes only needs that runtime to speak the CRI.

Kubernetes is the right pick when workloads genuinely benefit from horizontal scaling, self-healing, and multi-node scheduling, the platform team can run it, applications are already services rather than monoliths, and the operational cost is smaller than the value delivered (usually true above a certain fleet size). Docker is right when the workload doesn't need that complexity, the environment is small (single host, edge appliance, industrial gateway), the team doesn't want to acquire Kubernetes skills, and simplicity beats ecosystem breadth - single-instance databases and industrial data collectors are the clearest cases.

The mistake enterprises keep making is picking one and forcing everything into it: Kubernetes at the far edge is expensive and fragile; Docker for a large stateless web tier is under-tooled. Real estates use both, in the parts of the business where each fits. A platform that manages only one leaves half the estate ungoverned - which is why Portainer speaking to all three shapes, plus Podman, is a purposeful design position.

Above the runtime sits the platform management layer - where operator work happens. It covers multi-cluster fleet control, cluster templates, drift detection, policy propagation, secrets management coordination, registry management, environment grouping, and the human-facing surfaces that make the runtime usable by people who aren't writing YAML by hand.

This is where Portainer's primary value lives. Without a management layer you have a collection of runtimes, each handled by hand or by whatever tooling a given team likes, with no consistent way to apply a policy across the fleet or scope a team's access. That's a per-cluster operating model, and it stops scaling past about the third cluster.

It's also the layer most enterprises accidentally build themselves, badly: a pile of kubectl aliases, a Confluence page, a Slack channel, and one person who knows how the cluster was set up. That's not a management layer - it's a set of habits that won't survive that person leaving. Buying a management layer makes the operating model explicit, encoded, and portable to whoever's next on the roster.

Above management sits governance - audit, compliance, policy enforcement, and RBAC coordination. This is what security asks about, what auditors want evidence of, what a CISO signs off on before the platform goes anywhere production-adjacent.

It covers centralized authentication (federated to your directory), RBAC scoping, policy engines (Gatekeeper or Kyverno), network policies, image attestation, and audit logging - who did what, when, from where, and whether it succeeded.

In Portainer's model, governance and management are one product, not two stitched together, because running a separate governance product on top of a management product is expensive to integrate and expensive to keep integrated across upgrades. Governance without management is impossible to enforce; management without governance is dangerous. Keeping them together is a design choice.

Portainer Business covers layers 3 (platform management), 4 (security and governance), 5 (GitOps and configuration management), and 7 (operator and developer interaction) - four of seven, as one product, one release cadence, one support surface, one operating model.

Layers 1 (OS) and 2 (Kubernetes distribution) are addressed through partnership, not duplication. The Talos integration through Sidero Omni closes both for customers who want an integrated stack; customers who already have an OS and distribution choice keep it, and Portainer manages what runs above.

Layer 6 (deep observability) is a mix of embedded baseline observability and integration with whatever platform you already run. Portainer ships enough to know when things are on fire; for distributed tracing and long-retention metrics, you keep Datadog, Splunk, or your Prometheus stack - Portainer integrates rather than replaces.

Portainer doesn't provide a container runtime (use what you have: Docker, containerd, CRI-O, Podman), a Kubernetes distribution (bring your own or use Talos), a full observability platform (no tracing, no long-retention metrics, no APM - integrate with what you have), or syscall-level runtime security anomaly detection (that's Falco's job).

It doesn't provide a secrets management back end (integrates with Vault, cloud secret stores, or External Secrets Operator), backup and DR for cluster workloads (integrates with Velero, Kasten, or CloudCasa), a service mesh (deploy Istio or Linkerd for mTLS), or software-defined storage (keep your CSI).

It doesn't embed a container registry (Harbor, ECR, ACR, GAR, GitLab, whatever you use stays), doesn't run VMs (KubeVirt hosting is a deliberately declined scope decision), and doesn't solve Zero Trust networking at the enterprise perimeter (that's identity and network teams' territory).

Each of these is a deliberate scope decision. Portainer is worth deploying because it does what it does completely, not because it tries to do everything approximately.

Portainer's deliberate scope means partners have a real integration story. Every layer Portainer doesn't cover is a place a partner brings expertise, product, and margin.

At the OS and distribution layers: Sidero (Talos), Red Hat (RHEL, RHEL for Edge), Canonical (Ubuntu), and cloud providers (AKS, EKS, GKE, ROKS).

In industrial and OT: WAGO (edge PLCs, container-capable hardware), inray (industrial protocol integration), Softing (industrial data connectivity), 40Factory (industrial app deployment), and Innocens (industrial data platforms) - all delivered through the Industrial App Portal.

In observability and SIEM: OneUptime is the direct integration; Datadog, Dynatrace, Splunk, and Elastic sit alongside for deeper analysis and retention. Portainer streams audit and activity logs to syslog (RFC 3164 or RFC 5424, over UDP/TCP/TCP+TLS) - plumbing every SIEM in the market accepts.

In backup and DR: Velero, Kasten K10, and CloudCasa handle cluster-workload backup; Portainer covers management-plane backup itself (BoltDB snapshot to local, S3, or Azure Blob).

In secrets management: HashiCorp Vault (or OpenBao), External Secrets Operator, Sealed Secrets, and cloud-provider secret stores all coexist with Portainer, which consumes secrets rather than storing them.

You now know what a CMP contains, where Portainer draws its scope boundary, and where partners plug in. Module 3 walks Portainer's actual architecture next.