# Porter CNAB installer authoring for applications and tools > Porter packages an application artifact, client tools, configuration, and deployment logic into a distributable CNAB installer. It suits Go-based teams and platform engineers who need repeatable packaging across Docker, Kubernetes, cloud services, and command-line tools. **getporter/porter** — Porter enables you to package your application artifact, client tools, configuration and deployment logic together as an installer that you can distribute, and install with a single command. - Repository: https://github.com/getporter/porter - Website: https://porter.sh - Stars: 1,430 · Forks: 227 - Language: Go - License: Apache-2.0 - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/getporter-porter ## Porter's CNAB installer packaging model Porter solves a distribution problem that appears after an application has been built. Teams often have a container image, a command-line utility, a Helm chart, cloud configuration, and deployment automation, but those pieces still need to reach a customer or internal operator as one coherent installation unit. Porter wraps those assets and their installation logic into a bundle based on the Cloud Native Application Bundle specification, or CNAB. The result is described by the project as an installer that can be distributed and run with a single command. The intended users are application owners who know the desired deployment behavior and platform engineers who need that behavior packaged consistently. The distinction matters because Porter does not replace Docker, Kubernetes, Helm, Terraform, or cloud clients. Its role sits above those tools. It describes what must be installed, how the installation should proceed, and how applications such as Docker and Kubernetes are operated, while mixins provide access to each platform. This design is most useful when the application has more than one artifact or destination. A team can keep application-specific deployment logic beside declarations for the supporting tools. Porter then becomes the distribution boundary, rather than asking every recipient to assemble binaries and run a collection of manual setup commands. A simple application that already has an excellent installer script may gain little from that extra layer. ## How Porter manifests become a CNAB bundle Porter presents a declarative authoring model instead of treating an installer as an opaque shell script. According to the README, the bundle can contain the application artifact, client tools, configuration, and deployment logic. That arrangement suggests a bundle with several cooperating inputs rather than a single executable archive. The repository layout provides further evidence of the implementation path. Go sources are organized under `cmd/`, `pkg/`, `proto/`, and `gen/`, with examples under `examples/`. Its module dependencies include `github.com/cnabio/cnab-go`, `github.com/cnabio/cnab-to-oci`, and `github.com/google/go-containerregistry`. Those libraries connect Porter's authoring model with CNAB processing and OCI registry operations. The README does not document the complete build pipeline in the excerpt, so the precise conversion sequence should be checked in the porter.sh documentation before it is treated as an operational contract. At runtime, the conceptual flow is still specific. A distributed CNAB bundle contains the application payload and enough logic to carry out installation. Porter supplies the authoring and packaging tools used to produce that unit. Mixins connect the bundle logic to external platforms, while plugins provide separate paths for storing Porter data and retrieving secrets. The distinction avoids treating every credential store or backend as part of the installer format itself. ## Porter mixins for Docker, Kubernetes, Helm, and clouds Mixins are Porter's main integration layer for deployment tools. The README lists Docker, Docker Compose, Kubernetes, Helm, GCloud, Terraform, AWS, Azure, and `exec` as supported mixins. This coverage gives an installer a consistent way to invoke different deployment technologies without requiring every bundle author to implement each client integration from scratch. The mixin choice also exposes a practical boundary. Porter is most convincing when an installation genuinely spans external platforms or needs portable orchestration. A deployment that is only a static file copy into a directory may be better represented by a small native installer. Adding CNAB authoring in that case introduces more concepts without adding a useful distribution mechanism. The documented escape hatch is the `exec` mixin combined with a Custom Dockerfile. According to the README, users can create a mixin or use that route when a required custom mixin does not exist. This is important because the supported-platform list will never cover every internal tool. It also introduces an additional responsibility: whoever chooses this route must supply the container definition and execution behavior that the built-in integration would otherwise provide. Porter mixins are not universal remote-control interfaces for those platforms. They expose supported operations from inside a bundle. Platform support should not be interpreted as feature parity. Check the linked mixin documentation for the target technology before authoring an action that depends on an operation. ## Porter plugins, secrets, and operational dependencies Plugins address two responsibilities that should not be confused with mixins. The README states that Porter plugins store Porter's data and retrieve secrets from an external service. It lists Hashicorp, Azure, and Kubernetes as available plugin platforms. A mixin such as Docker or Helm performs application-facing operations, while a plugin selects where Porter data and sensitive values are handled. That separation gives bundle authors options for installations that cannot safely embed operational access in the bundle. It also creates a dependency decision. Selecting a plugin means accepting its service model and, depending on the implementation, configuring access to that service during installation or operation. The README excerpt does not document configuration keys, environment variables, authentication methods, or failure behavior for any plugin. No such values should be guessed. The operational risk is different from ordinary package-manager concerns. An installer may automate a deployment while obtaining credentials from Azure, Kubernetes, or another external system. Teams should therefore verify where each secret is stored, how the plugin obtains it, and what happens when the external service is unavailable. Porter provides the extension point, but the README does not establish whether a credential operation is retried, cached, or performed interactively. ## Porter installation and first bundle documentation path The README directs readers to porter.sh for full documentation. The documented starting point is the project documentation site, followed by the examples directory in the repository. The README describes declarative authoring and offers the `exec` mixin with a Custom Dockerfile as a fallback, but that does not constitute a complete tutorial. A new user should first locate instructions for obtaining the Porter binary for the required platform, then use an official example that matches the intended destination, such as Kubernetes, Helm, or Docker. The repository also includes `docs/` and `examples/`, while `examples/README.md` is present. Those are the concrete places to consult for document structure and sample selection after the installation instructions are found. The module file begins with `module get.porter.sh/porter` and declares `go 1.26.9`, but those lines describe the source module and its Go requirement, not a user-facing installation procedure. ## Porter release status and upgrade considerations The repository is not archived, and its last push was on 2026-10-14. Those facts support calling it maintained at the time of this review, although a recent commit alone does not guarantee compatibility with a particular installer. Release information needs careful interpretation. The available release list includes `v1.6.1`, dated 2026-07-17, but it also contains older entries labeled `canary` and `latest` from 2021-04-06. A team should select an immutable version deliberately rather than assuming that a tag named `latest` represents the newest code. Porter's Apache-2.0 license permits use and modification under that license's conditions. Users distributing a generated bundle should also account for bundled applications, client tools, container assets, and plugin dependencies rather than assuming Porter's license automatically settles every distribution question. This is a review checklist, not legal advice. Upgrades can affect several layers because one bundle may call multiple mixins and a plugin. The README does not document a rollback procedure, manifest migration policy, or compatibility matrix. Those omissions matter when an installer has already been published to users. ## Porter versus a shell installer or Helm release A shell installer is the clearest alternative. It can package several files into an archive, install binaries, and run deployment commands directly on the target host. That approach has fewer abstraction layers and can be easier to inspect for a narrowly defined installation. Its weakness is that every recipient needs the required local tools, and portable orchestration must be implemented outside the installer. Porter instead formalizes those assets as CNAB content and exposes platform operations through mixins. Helm is another alternative when Kubernetes is the only destination and the installation is already well modeled as a chart. A Helm release is the primary artifact in that case, while Porter becomes the outer installer that may also carry client tools or coordinate work beyond Kubernetes. If the deliverable must work across Docker, Kubernetes, Helm, and cloud APIs, a plain chart is too narrow. The decision is therefore about the delivery boundary. Use Porter when distribution and multi-platform orchestration justify a declarative bundle. Prefer a shell script when there is only one supported operating environment and minimal setup logic. Prefer Helm when the product is specifically a Kubernetes release and does not need a broader installer. Porter's value comes from CNAB packaging, not from replacing Helm or Kubernetes. ## Conclusion Porter is a reasonable choice for Go-based application teams that want one versioned installer across containers, Kubernetes, and external services, especially when CNAB distribution is already part of their delivery model. It is a poor fit for teams wanting a small shell installer with no bundle runtime or declarative manifest. Before adoption, verify the documented workflow for packaging your exact target platforms, verify runtime credential handling against the relevant plugin, and confirm that v1.6.1 covers the mixins and upgrade path required by your installer. ## FAQ ### What is Porter used for? Porter packages an application artifact, client tools, configuration, and deployment logic into a distributable installer based on CNAB. ### Which platforms does Porter support through mixins? The README lists Docker, Docker Compose, Kubernetes, Helm, GCloud, Terraform, AWS, Azure, and `exec` as supported mixins. ### How do Porter plugins differ from mixins? Plugins store Porter data and retrieve secrets from an external service, while mixins provide integrations for tools and platforms used inside a bundle. ### Can Porter run a tool without a built-in mixin? The README says users can create a mixin or use the `exec` mixin with a Custom Dockerfile when a required custom mixin is unavailable. ### What license does Porter use? Porter uses the Apache-2.0 license. Users should separately review the terms of applications, client tools, container assets, and dependencies included in a generated bundle. ## Sources - [getporter/porter on GitHub](https://github.com/getporter/porter) - [License: Apache-2.0](https://github.com/getporter/porter/blob/main/LICENSE) - [Project website](https://porter.sh) - [README](https://github.com/getporter/porter/blob/main/README.md) - [Releases](https://github.com/getporter/porter/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/getporter-porter