What a platform is.

Before you can decide where Portainer fits, you need a shared picture of what a container management platform contains. The industry uses "container platform" to mean whatever the vendor happens to sell, which is why the term has stopped being useful in a technical conversation. This module gives you the specific vocabulary the rest of the course will use.

A complete enterprise container platform spans seven distinct layers, each of which introduces operational responsibility, integration cost, and risk. Those layers are: 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 do not have to build all seven yourself; the market is full of products that cover one or several. The point of pinning down the seven-layer picture is that it lets you say what any given product does and does not cover, and where the gaps are that you have to fill yourself. Every enterprise container platform decision is a decision about which layers you buy, which layers you build, and which layers you decide are somebody else's problem.

The bottom of the platform stack is the runtime. There are essentially three shapes of runtime 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, without orchestration; it is what shipped first, and it is what most developers still install locally when they are learning. It is fine for a lot of workloads (single-instance stateful services, edge appliances, industrial gateways), and it should not be dismissed just because Kubernetes exists.

Docker Swarm orchestrates containers across a cluster of Docker hosts, using Docker's own primitives (services, stacks, overlays); it is simpler than Kubernetes, has none of the CNCF sprawl around it, and continues to be a legitimate choice for existing Swarm operators where operational simplicity matters more than the CNCF ecosystem. The honest position on Swarm's long-term future is that nobody knows; it may continue to work well for many years, or it may not, and that is the risk. That is why Portainer released D2K: to give Swarm shops a way forward onto Kubernetes without retooling the applications themselves, when the day comes that they need to move.

Kubernetes is the default answer at scale in most enterprises now; it orchestrates containers across a cluster of nodes with a much richer object model, a bigger ecosystem, and a much bigger operational surface. Kubernetes is not a runtime by itself; underneath the API is containerd, CRI-O, or another OCI runtime, and Kubernetes only cares that the runtime speaks the CRI.

Portainer manages all three shapes of runtime, plus Podman on the standalone side (podman is a Docker-compatible engine some enterprises pick for its rootless posture). This matters because your customer's estate probably has all three shapes running somewhere, and any container platform that only speaks one of them leaves the others ungoverned.

The Docker-versus-Kubernetes question comes up in every real enterprise conversation; the honest answer is that both continue to exist, and pretending otherwise costs you credibility with people who run this stuff for a living.

Kubernetes is the right pick when you have workloads that genuinely benefit from horizontal scaling, self-healing, and multi-node scheduling; when you have a platform team big enough to run it; when your applications have already been designed as services rather than monoliths; and when the operational cost of running Kubernetes is smaller than the value it delivers, which is usually true above a certain fleet size.

Docker (Standalone or Swarm) is the right pick when the workload does not benefit from Kubernetes complexity; when the environment is small (single host, edge appliance, industrial gateway); when the team running it does not have Kubernetes skills and does not want to acquire them; and when the total-cost calculation favors simplicity over ecosystem breadth. There is a class of workload (single-instance databases, single-instance stateful services, industrial data collectors) where Docker is just the correct answer.

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-scale stateless web tier is under-tooled. Real estates use both, in the parts of the business where each is the right fit. A platform that manages only one leaves half the estate ungoverned, which is why Portainer's ability to speak to both is not a legacy accident; it is a design position.

Above the runtime sits the platform management layer, which is where operator work happens. This layer 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 consumable by people who are not writing YAML by hand.

This layer is where Portainer's primary value lives. Without a management layer you have a collection of runtimes, each managed by hand or by whatever tooling that team happens to like, and no consistent way to say "apply this policy across the fleet" or "give this team access to those three environments." You end up with a per-cluster operating model, which does not scale past about the third cluster.

The management layer is also the layer that most enterprises accidentally build themselves, badly. A collection of kubectl aliases, a Confluence page, a Slack channel, and one person who knows how the cluster was set up is not a management layer; it is a set of habits that will not survive that one person leaving. The point of buying a management layer is to make the operating model explicit, encoded, and portable to the next person on the roster.

Above the management layer sits the governance layer, which is where audit, compliance, policy enforcement, and RBAC coordination live. This is what your security team asks about; it is what your auditors want evidence of; it is what your CISO signs off on before a container platform gets deployed anywhere production-adjacent.

The governance layer covers centralized authentication (federated to your directory), RBAC scoping (who can do what in which environment), policy engines (Gatekeeper or Kyverno enforcing what workloads can run), network policies (which pods can talk to which), image attestation (has this image been signed, is it from an approved registry), and audit logging (who did what, when, from where, and did it succeed).

In Portainer's model, governance and management are the same product, not two products stitched together, because the alternative (running a separate governance product on top of a management product) is expensive to integrate and expensive to keep integrated across upgrades. Portainer's opinion is that governance without management is impossible to enforce, and management without governance is dangerous; keeping them together is a design choice, not a feature list.

Above the governance layer sits the interaction layer, which is what consumers of the platform actually touch. Consumers here means both operators (the platform team, on-call engineers, admins) and end users (developers deploying apps, industrial operators deploying line-of-business software, security teams pulling audit trails).

Different consumer classes need different interfaces. An operator wants a full-fleet console with deep visibility and administrative controls; a developer wants a self-service path to deploy their application without needing to understand what a service account is; an industrial operator wants a portal that shows machines and applications in the hierarchy their site is organized around, with no exposure to container concepts at all.

Portainer's strategy separates operator control from user interaction. The main Portainer Business UI is the operator control plane. The Industrial App Portal is a dedicated product on top of that plane, built for OT operators who navigate an ISA-95 site/area/work-center hierarchy and deploy from an admin-approved catalog, with Docker and Kubernetes invisible to them entirely. Portainer-Run is a developer-facing deployment surface for the "vibe-coded" app case, sitting on the same operator control plane but with a very different UX. The point is that one operator control plane can drive multiple consumer surfaces without duplicating the underlying governance model.

Now the map. Portainer Business covers layers 3 (platform management), 4 (security and governance), 5 (GitOps and configuration management), and 7 (operator and developer interaction) as its primary territory. That is four of the seven layers, delivered as one product, with one release cadence, one support surface, and one operational model.

Layers 1 (operating system) and 2 (Kubernetes distribution) are addressed through partnership rather than duplication. Portainer's Talos integration through Sidero Omni closes the OS and distribution layers for customers who want an integrated stack; customers who already have an OS choice (RHEL, Ubuntu, Amazon Linux) and a distribution choice (EKS, AKS, RKE2, k3s, whatever) keep the ones they have, and Portainer manages what runs above them.

Layer 6 (deep observability and telemetry) is addressed through a mix of embedded baseline observability inside Portainer itself and integration with the observability platform you already run. Portainer ships enough to know when things are on fire; if you need distributed tracing and long-retention metrics, you keep the observability platform you have. Portainer does not try to replace Datadog, Splunk, or your Prometheus stack; it integrates with them.

Being explicit about what Portainer does not do matters, because pretending a product covers more than it does is how you lose credibility three months into a deployment. Here is the list, plainly.

Portainer does not provide a container runtime; the runtime you have (Docker, containerd, CRI-O, Podman) is what you use. Portainer does not provide a Kubernetes distribution; you bring the distribution or use Talos through the integration. Portainer does not provide a full observability platform (no distributed tracing, no long-retention metrics store, no application performance monitoring); you keep the observability platform you have and integrate. Portainer does not provide runtime security anomaly detection at syscall level; that is Falco's job, and you keep Falco.

Portainer does not provide a secrets management back end; it integrates with Vault, cloud-provider secret stores, or External Secrets Operator. Portainer does not provide backup and disaster recovery for cluster workloads; it integrates with Velero, Kasten, or CloudCasa. Portainer does not provide a service mesh; if you need mTLS between services, you deploy Istio or Linkerd. Portainer does not provide software-defined storage; the CSI you have is the CSI you keep.

Portainer does not embed an enterprise container registry; Harbor, ECR, ACR, GAR, GitLab Container Registry, whatever you use, that is what stays. Portainer does not run VMs (VM hosting through KubeVirt is a legitimate scope decision Portainer has deliberately declined). Portainer does not solve Zero Trust networking at the enterprise perimeter; that lives above the platform, in your identity and network teams.

That list is not an apology. It is a scope decision, made deliberately, and repeated in every module. The reason Portainer is worth deploying is that it does what it does completely, not that it tries to do everything and does it approximately.

The deliberate scope of Portainer means partners have a real integration story rather than a marginal one. This matters if you are reading this as an integrator; every layer Portainer does not 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), Ubuntu (Canonical), and cloud providers (AKS, EKS, GKE, ROKS) are the standard integration points. Portainer manages what runs above; the partner provides what runs below.

In the industrial and OT space, WAGO (edge PLCs and container-capable industrial hardware), inray (industrial protocol integration), Softing (industrial data connectivity), 40Factory (industrial application deployment), and Innocens (industrial data platforms) all fit above or beside Portainer. The Industrial App Portal is the surface these partners' applications get delivered through.

In the observability and SIEM space, Datadog, Dynatrace, Splunk, Elastic, and the OneUptime integration Portainer ships are all legitimate paths. Portainer streams audit and activity logs to syslog with configurable format (rfc3164 or rfc5424, over UDP/TCP/TCP+TLS), which is the plumbing every SIEM in the market accepts.

In the backup and DR space, Velero, Kasten K10, and CloudCasa are the standard integration points for cluster-workload backup; Portainer covers the management plane backup itself (BoltDB snapshot to local, S3, or Azure Blob) and coordinates with these products for workload-layer protection.

In the secrets management space, HashiCorp Vault (or OpenBao), External Secrets Operator, Sealed Secrets, and cloud-provider secret stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) all coexist with Portainer. Portainer does not try to be a secrets store; it consumes them.

Module 3 is where architecture stops being abstract. You are going to learn what the Portainer Management Server actually is, what the Portainer Agent does (three flavors: standard, edge standard, edge async), how the reverse tunnel between the server and an edge agent actually works, and how the datastore is structured. When you finish Module 3, you can pick the right agent mode for each environment you plan to onboard, and you can explain to a security team what network paths exist between components and why.

Module 4 is where the lab starts. Module 3 is the last of the reading modules, and it is the one that gets you architecturally ready.