Porter – Blog

Porter 1.6.0: Porter Now Speaks MCP

Wed, 29 Jul 2026 00:00:00 +0000

Porter 1.6.0: Porter Now Speaks MCP

Porter 1.6.0 is out, and the headline feature is one we’re genuinely excited about: Porter now speaks MCP.

If you’ve been packaging your apps, tools, and deploy logic into Porter bundles, you already know the value of having one distributable, versioned unit instead of a pile of scripts. This release makes that unit easier to work with than ever — including, for the first time, by an AI assistant sitting right next to your terminal.

`porter mcp`: an AI assistant that actually knows your bundles

Running porter mcp starts an MCP (Model Context Protocol) server over stdio. If you’re using an AI coding assistant that supports MCP — Claude Code, Cursor, and VS Code Copilot all do — that assistant can now talk directly to Porter instead of guessing from your porter.yaml.

In practice, that means you can ask things like:

“What does this bundle actually install?”
“Show me the installations running in the prod namespace.”
“Walk me through what would change if I upgrade this bundle.”

…and get answers grounded in what Porter actually knows, not an educated guess based on static file contents. For anyone who’s ever had an assistant hallucinate a plausible-sounding but wrong answer about a deploy script, this is the fix: the assistant is querying Porter’s real state, the same way you would from the CLI.

By default, the server only exposes read-only tools — safe to point an assistant at without worrying it’ll change anything. If you want your assistant to actually install, upgrade, uninstall, or invoke bundles on your behalf, start the server with --allow-write to opt in to those mutating tools explicitly.

We think this is a meaningful shift in how bundles get explored and operated day-to-day, and it’s just the first step — expect more MCP-native workflows in future releases.

Try it now:

# read-only: explore and inspect bundles and installations
porter mcp

# read-write: also allow install, upgrade, uninstall, and invoke
porter mcp --allow-write

Point an MCP-compatible client at it — for Claude Desktop, that’s:

{"command": "porter", "args": ["mcp"]}

Then ask it about a bundle you’re already working with — that’s the fastest way to see what’s changed.

Also new in 1.6.0

MCP is the headline, but this release carries a handful of other improvements worth knowing about:

Dependency version ranges. When a dependency declares a version range instead of a pinned tag, dependencies.version-strategy now controls how Porter resolves it: exact (the default — refuse to resolve ranges, and error if no pinned tag is given), max-patch, max-minor, or min. Set it in the config file, override it with PORTER_DEPENDENCIES_VERSION_STRATEGY, or per-command with --dependencies-version-strategy. Full details in the Configuration docs.

Experimental file sources. porter.yaml can now declare files that Porter downloads over HTTP/HTTPS at build time, rather than requiring everything to be pre-placed in the bundle directory. This requires schemaVersion: 1.3.0 and the file-sources experimental flag — and, since downloading arbitrary URLs into a bundle build has real security implications, it’s blocked by default even then. You also need to explicitly set allow-file-downloads: true (or pass --allow-file-downloads to porter build), and should only do so for bundles whose declared URLs you trust. Still experimental, and we’d love feedback from anyone who tries it against a real bundle.

Graceful shutdown. Hitting Ctrl+C during a Porter operation now forwards a proper SIGTERM with a grace period, instead of killing things abruptly. If your bundle has cleanup steps or outputs that need to finish writing, this means far less risk of losing them to an interrupted run.

Reliability fixes, including:

porter publish --archive now works correctly for bundles built with Docker 29.x’s containerd image store, whose invocation image layout can be an OCI image index rather than a plain manifest — if you’d hit publish failures after upgrading Docker, this should resolve them
Correct parameter-set precedence when running an upgrade
porter explain now shows parameters that were injected automatically, not just the ones you specified
A fix for porter-state corruption that could occur with custom actions marked modifies: false

Full details, as always, are in the GitHub release notes.

Where dependencies are headed next

If you work with Porter’s dependency system, you’ve probably felt its current limits: every dependency creates a brand-new installation, even when you’d rather point at something that already exists — a shared database, a cluster-wide operator, infrastructure someone stood up by hand outside Porter entirely.

We’re actively working on Dependencies v2, a more flexible model that supports sharing an existing installation across multiple bundles, scoping that sharing by group or namespace, and depending on any bundle that satisfies a contract (think “any bundle providing MySQL 5.7”) rather than a hardcoded reference. The design is laid out in PEP003 - Advanced Dependencies.

The dependencies-v2 experimental flag exists today, but the functionality behind it is still being built out incrementally — so turning it on gets you a work-in-progress, not the complete feature set described in the PEP just yet. If you want to follow along closely or try what’s there so far, you can enable it using any of Porter’s standard ways to set an experimental feature flag — a CLI flag, an environment variable, or the config file. Expect rough edges and gaps, and consider anything you see subject to change.

One concrete way to see it in action already: porter inspect --show-dependencies resolves and displays a bundle’s full transitive dependency graph, not just its direct dependencies — shared dependencies get deduplicated to a single node, and for Dependencies v2 (shared) bundles specifically, it detects and shows the output-wiring relationships between sibling dependencies. It’s one of the clearest windows into what the shared model actually does today. Worth noting: execution (install/upgrade/uninstall) currently only resolves a bundle’s direct dependencies — transitive dependencies aren’t automatically installed yet, though it’s on our backlog.

The version-range work in this release is a small but real piece of that larger direction — we’ll follow up with a full write-up once Dependencies v2 is further along.

Feedback welcome

Found a bug? Please open an issue on GitHub. For questions, ideas, and “here’s what I wish this did” feedback, GitHub Discussions or #porter on the CNCF Slack are the best places to reach us.

So, You Want to Share a Cloud Application?

Mon, 06 Nov 2023 00:00:00 +0000

by Brian DeGeeter and Steven Gettys

We’ve all been there. You’ve done all the work to create a GitHub repo with the code needed to show off some cool new cloud application architecture. We all know there’s never one tool to rule them all. It’s a bit of Terraform, a healthy dose of Ansible, and of course some Bash to connect it all together.

You’ve done your homework and tested everything out. Deployed it countless times from your laptop. Then you get it out there for others to see. You’re waiting to get that feedback from someone asking about the solution or comment about how it solves their problem. But that’s not what you hear first. Instead, it’s, “I’m getting a Terraform error, can you help me troubleshoot?”

It’s always something simple. The terraform code did not declare a specific version for compatibility with the user’s version or the wrong version of python is installed for the Ansible role. At the end of the day, it becomes the gap between that first experience you were hoping someone would have and an environmental issue.

This is where Porter and CNAB bundles come into play. Don’t worry this is not about replacing the arduous work you’ve already done. It’s about packaging it such that it’s easier for you to maintain and for your users to engage. No more having to worry about the environment your DevOps code runs in. Porter provides an opinionated workflow for packaging a versioned instance of your cloud deployment

No more confusion for your users as well. The same Porter command line tool used by a maintainer for ownership of a cloud deployment is used to deploy. Your users can install your cloud architecture with just a reference to a versioned OC (docker) container image.

No need to worry about tool dependencies, just run:

porter install reference github.com/bdegeeter/JoyOfNginx/Nginx-OSS:v0.1.0

Now you’ll end up right where the bundle maintainer expects you to be.

What is a Cloud Native Application?

At its heart, a cloud native application is one expected to be deployed via code. This can be on any of the well-known public clouds (Azure, AWS, GCP, etc.). It also encompasses private cloud platforms like an on prem VMware cluster.

Depending on one’s needs this can be the deployment of a SaaS workload on a pre-existing cloud Kubernetes instance. However, it can also encompass a full stack platform with an opinionated deployment of compute, networking, storage, IAM, and more. And while we are talking specifically about cloud native, Porter can really help with anything that could be fully automated and run in a Docker container

What is CNAB/Porter?

CNAB

A Cloud Native Application Bundle (CNAB) specification for packaging and distributing cloud native applications. It is designed to be an open, portable, and secure way to distribute cloud native applications and their dependencies.

CNAB bundles are composed of several components, including:

A manifest file that describes the contents of the bundle, including the application and its dependencies.
The application itself, which can be packaged as a container image or a collection of files
Dependencies of the application, which can also be packaged as container images or collections of files.
Installation instructions, which are used to deploy the application and its dependencies to a cloud platform.

One of the key benefits of CNAB bundles is that they provide a single, portable package for distributing cloud native applications. This makes it easier for developers to deploy their applications to different cloud platforms, as the application and its dependencies are all contained within the CNAB bundle.

CNAB bundles also have built-in security features, such as cryptographic signing and verification, to ensure the integrity and authenticity of the bundle. This helps to prevent tampering or modification of the bundle during the distribution process

In addition, CNAB bundles are designed to be extensible, allowing developers to add custom metadata and functionality to their bundles. This enables developers to include additional information and instructions that are specific to their applications, such as configuration settings or post-installation steps.

Overall, CNAB bundles provide a flexible and secure way to distribute cloud native applications, making it easier for developers to deploy and manage their applications across different cloud platforms.

Porter

Porter is a CNCF project implementing the CNAB specification. It provides a CLI and Kubernetes Operator to create, publish, install, and maintain CNABs. Porter provides a consistent, platform-agnostic way to deploy and manage cloud native applications, making it easier to automate and manage the lifecycle of your applications.

Problems Facing Modern Cloud Solution

Embarrassment of Riches

There has been an explosion of choices in tooling all with the same goal in mind, automate the deployment of your cloud architecture with an application solution. CNAB bundles provide a common interface for any arbitrary Infrastructure as Code (IaC) tooling.

A CNAB Bundle not only contains your IaC, but also the runtime environment for execution. From a user’s perspective it doesn’t matter what tools are needed. The bundle publisher selects the best choice and doesn’t need to worry about what’s installed on the bundle installer’s system

Simplify and Speed Up Deployments

It’s possible to do some interesting things via bundles. We’re all aware of the problems of “eventually consistent” cloud deployments. While your cloud provider may be still provisioning your Kubernetes cluster, your DevOps code is ready to deploy a workload on top! Within the steps of a bundle, it can wait for conditions to be met before proceeding. Need that Kubernetes system service to be up or Custom Resource Definition (CRD) loaded before deploying a workload on top? A bundle maintainer can account for it in the deployment.

Porter can also accommodate more advanced use cases by allowing a bundle to be made up of other bundles. Do you need the same solution for different cloud providers? Create bundles such that a base for the provider has the same outputs needed to layer your solution on top. Then create a wrapper bundle for a one step deploy to a specific provider.

Why should I care?

Isn’t this just another DevOps tool in a world already saturated with them? Why would I want to spend the time learning about a whole new ecosystem when what I really need is to get solutions out to customers?

Well, I’m glad you asked!

Accelerating Solution Adoption

The best application is only as good as its ability to be deployed and installed. No matter how useful or innovative your application is, if it is difficult to deploy and run then that can prevent it from ever seeing the light of day.

Let’s take a couple of concrete examples:

JoyOfNGINX

Check out the JoyOfNGINX Repo. This is a great collection of automated components that will deploy the necessary infrastructure and provision an NGINX deployment.

The installation process is simple and straightforward with only a few requirements:

Microsoft Azure account for deploying the infrastructure into,
Latest version of Terraform that will be used to create the Azure infrastructure,
Latest version of Ansible that will be used to provision the Azure infrastructure with NGINX,
An OS that can run Bash to tie Terraform and Ansible together nicely.

The workflow to deploy depends on the user having enough knowledge about Terraform and Ansible to run them locally, as well as following multiple steps in the different subdirectories. Each additional tool and step adds another contact point that can quickly lead to an error.

Additionally, what the “latest version” of a tool means today is something completely different than what it might mean in six months or a year. Tooling updates break backwards compatibility or introduces new assumptions all the time. This can be alleviated by aggressively locking down tooling versions or dependencies but can only be taken as far as the tool or a process supports.

Enter CNAB and Porter.

A Porter bundle can be created that holds all tooling versions, scripts, local files, and dependencies.

This reduces the steps required to install the application to two:

Setup the Porter Credential Set with the necessary Azure Service Principal credentials
Run porter install.

No more managing local versions of Terraform and Ansible or requiring that this runs on a system with a particular version of Bash. No more worrying about future versions of tools not being compatible with the code in the repo. No more “runs on my machine” because everything needed to install the application exists inside of the published and versioned Porter bundle!

Every single run of the application will always use the same versions and the application can be installed without ever cloning a git repo or installing more tools locally. This greatly reduces the number of potential errors a user will run into while installing an application, and fully automates the entire application lifecycle management.

NGINX Unit on KinD (Kubernetes in Docker)

The NGINX Unit Demo bundle shows a different way to use a bundle. Instead of deploying a production solution in the cloud this bundle creates a KinD Kubernetes cluster on the user’s system and installs a local example of NGINX Unit running on k85 with ingress configured. It takes advantage of Porter’s ability to support bundles that need access to the local docker host.

The bundle definition file sets docker as a requirement which translates to the end user needing to set the --allow-docker-host-access command line flag explicitly when installing.

Porter Argo Demo

Really want to dive deep? Check out the Porter Argo Demo. This repo has everything you need to run the Porter Operator with Argo Workflows to see the operator in action with Jaeger and OpenTelemery for observability

It’s important to take away that Porter and CNAB bundles don’t replace how your automation works. Instead, it provides a powerful workflow for maintaining and sharing your work for all kinds of use cases.

Security and Reliability

There are many benefits Porter can provide when creating cloud-native applications:

Bake security best practices directly into the bundle. Add an auditable stage to your secure supply chain knowing that there were no shortcuts taken when a particular version of an application bundle was deployed!
Since all aspects of the application are included in the bundle there is a high level of confidence that the application will install the same way every single time.
Air-gapped installations provide higher security and the ability to know exactly what will be installed every time. A bundle can be developed and approved by a security team and then installed with confidence knowing that versions of packages and libraries will not be inadvertently updated at runtime.
Bundles can be combined into a single bundle allowing for a more reliable delivery of the full application platform.

The Value of Porter

Let’s contrast the work necessary to get the same value the porter workflow provides.

Do you ask users to clone a repo and manually run a set of instructions?
Do you provide a custom internal script to connect a bunch of DevOps solutions together?
Do you maintain a container with all the tools necessary to run your DevOps code?

Use Case	Internal Tooling	Porter	Porter Value
The same version of Terraform, Ansible, Python, Salt, Puppet, Node, etc., is used by everyone to deploy:	Readme with details of what user must install or maintain a container with everything needed.	The definition of the container runtime environment is with the DevOps code. It includes best practice workflow for common DevOps technologies.	Less maintenance overhead. As your application changes the runtime for executing follows.
Different versions of the application can be deployed reliably every time:	It’s up to the team owning the workflow to develop a process to keep things in sync. That can be custom internal tools or just documentation.	Porter’s build and publish workflow requires semantic versioning. Docker registry 2.0 supports metadata to link runtime image to code image.	It’s one step for user to reference an image tag. That tag has references to the runtime image. Less to keep in sync for maintainers and less work for users.
Consistent application lifecycle management independent of DevOps technology:	Keep multiple project’s documentation or internal scripts up to date and consistent.	One command CLI interface independent of the DevOps tooling under the hood.	Your users just need to know a single tool and workflow.
Ensure best practices for secret/credentials injection:	Another internal process that must be maintained by one or more teams.	Porter by design abstracts inputs and credentials. Namespaces provide access to different secret stores at runtime.	Takes all your existing application code and provides a better security model around it quickly.
Workflow with community support and contributions:	Maintaining many custom internal tools that can vary between teams and orgs.	Mixins, CNCF supported, slack support. Not a custom internal tool.	Align on common practices that leverage the DevOps code you already have.

Call to Action

We all know what it’s like to be in the trenches with all your focus on automating deployments. The pressures of release cycles. When does one find time to learn a new tool or technology that perhaps could help? As one who’s been there for many years and watched the landscape change, this is one of those times to stop, take a pause, and take a new technology for a test drive. Porter and CNAB are not about replacing the hard work you’ve done over the years. They’re about improving the workflow around it. Maybe you have great security and maintenance practices in place already. If so, Porter’s ready for you. Maybe this is something that’s still on your to-do list? If so, Porter’s ready to take some of the weight of that work off your shoulders.

Try out some of the examples presented here. Reach out to us in the Porter community.

Porter Operator v1.0.0 is here!

Thu, 28 Sep 2023 00:00:00 +0000

Porter Operator v1.0.0 is finally here! 🎉

What is the Porter Operator?

The Porter Operator gives you a native, integrated experience for managing your bundles from Kubernetes. It is the recommended way to automate your bundle pipeline with support for GitOps.

What’s new in v1?

Outputs

🚨 Outputs is currently WIP, we will be following up shortly with the ability for outputs to work after an installation upgrade.

Our biggest feature by far is the Outputs API. Being able to share outputs between bundles, services, and allow users to retrieve outputs from bundles is a must have. By creating the installation.outputs CRD we are now able to expose those outputs. We leverage the work done in Porter to turn a gRPC server which enables for these outputs to be shared for a variety of use cases.

Delete all the things!

There were a myriad of issues we were running into when trying to delete resources. One of these issues being that a finalizer would block the deletion of a namespace. By updating one of our reconcilers to check that a deletion timestamp was set, the deletion of namespaces which have operator resources is now able to occur.

The TTLSecondsAfterFinished agent configuration option is out, which allows users to set the time limit of a job that has finished its execution. This defaults to 600 seconds, but in the long term should allow for easier debugging.

Checkout the Operator Demo

If you’d like to take the Operator for a spin please go through out Quickstart here. However, if you’re looking for something with more fun tools included, Brian DeGeeter has this amazing porter-argo-demo.

Recognizing our key contributors

None of this would have been possible without the following:

Porter v1.0.0 is here!

Wed, 27 Sep 2023 00:00:00 +0000

Porter v1.0.0 is finally here! 🎉

What is Porter?

Porter takes everything you need to do a deployment—command-line tools, configuration files, secrets, bash scripts, and the application itself—and glues it all together. Then Porter packages that into a versioned bundle distributed over standard OCI registries or plain tgz files. With Porter, anyone can install your application without needing deep knowledge of your deployment process or underlying tech stack.

Learn more about Porter:

What’s new in v1?

If you haven’t been following Porter’s v1 pre-releases, below are some of the new features introduced since v0.38.

Buildkit Support

Porter now uses Docker Buildkit instead of legacy Docker to build images. This dramatically speeds up the build process and allows you to take advantage of features such as build arguments, improved layer caching, new Dockerfile syntax, mounting secrets and ssh connections into the image during build and more.

Installations

Porter now understands the concept of installations. You can see the current definition of an installation, the bundle it’s using, its version, the associated parameters and credentials, logs from previous runs, and metadata about the installation’s current state. Installations can be isolated in namespaces and have labels applied to them to make it easier to manage multiple installations and environments.

Porter also supports specifying the desired state of an installation (or credential set, parameter set). Porter will reconcile that against its database and determine the appropriate action to execute, if any, to reach that state. This makes it much easier to automate running Porter based on triggers such as a git push, or when a new version of a bundle is released, without having to deal with figuring out if you should call install or upgrade, and other things that Porter can figure out for you.

Desired state also supports the upcoming Porter Operator, a Kubernetes operator that automates running Porter on a Kubernetes cluster, similar to the Helm Operator. The operator is still under development but is coming up on our roadmap now that Porter v1 is live.

Improved Data Persistence

Previously, we supported Azure Blob Storage, Azure Tables, and storing data as files in your home directory. Porter now stores its data in Mongodb, for improved query performance when working with larger databases. You can use Mongo Atlas, Azure CosmosDB with Mongo API, or any Mongodb instance with Porter.

In addition to changing Porter’s database, we have eliminated sensitive data from the database altogether. Porter has always resolved and injected secrets into a bundle Just-In-Time from a secret store such as Hashicorp Vault or Azure Key Vault. With Porter v1, when we need to work with sensitive data, it is persisted back to your configured secret store. This includes sensitive data in your config file, such as tokens or connection strings. Your configuration file can now load sensitive data directly from your configured secret store so that your database or config file can’t be used gain access to sensitive data.

Tighter Security

We have lots of bug fixes around connecting to OCI registries and remote Docker daemons both in production environments and in development.
Porter resolves referenced image tags to digests when the bundle is built, ensuring that your bundle pins its dependencies.
Bundles no longer run as root.
Porter images are now redistributed on the PlatformOne IronBank registry. These images are built on an isolated network, regularly scanned for CVEs, and new releases are available on average 1-2 days after the official Porter releases on GitHub.
Porter publish checks for an existing bundle at the destination location to avoid accidentally overwriting a published bundle. You can still force push a bundle, but it’s opt-in now.

Read more about Porter’s security features.

What’s next?

Our v1 release is not a stopping point, but instead a way point where we can now say “Porter is stable and safe to use in production”. We have big plans going forward, adding new features on top of v1 incrementally:

Advanced Dependencies: Our initial implementation of dependencies was always limited in scope. More complete and powerful dependency support is already underway. Learn more in PEP003 Advanced Dependencies.
Distribute Mixins as Bundles: After we have advanced dependency support, we are improving how mixins are distributed and executed so that they are BUNDLES! This will significantly improve performance, layer caching, mixin distribution, and bundle execution security. Learn more in PEEP005 Mixins are Bundles.
Porter Operator v1: The Porter Operator is far enough along for you to try, and we aim to quickly get it ready for a v1 release.
Support for signing bundles: Porter will support integration with Notary for signing and verifying bundles.

Porter's 2023 Roadmap

Tue, 31 Jan 2023 00:00:00 +0000

Now that 2022 is finally over and Porter v1 is out the door, I’d like to share our plans for this coming year.

You can find a review of 2022 and our high level plans for 2023 in our Porter Annual Review for 2022 but let’s go over the highlights for a sneek peak of what’s to come.

Porter Operator

The Porter Operator is a Kubernetes operator that runs bundles on your cluster. With the operator you can:

Automate running bundles on Kubernetes
Upgrade to new versions of bundles when they are released
Integrate bundle deployments into your existing pipelines

Many users, especially adopters with large-scale Porter deployments, are eagerly awaiting managing their installations using a GitOps based workflow with the Porter Operator and Flux. We made great progress on the operator last year and our v1 milestone outlines the remaining work necessary for a stable release.

The operator is ready to try out and we would love your feedback! We have a quickstart that walks you through installing the operator and running a bundle. Give it a shot and let us know what you think.

Advanced Dependencies

Porter plans to support advanced workflows and dependency scenarios (PEP003), where users can define bundles that have a complex dependency graph. Dependencies may be an interface such as requiring a MySQL database whether it came from a dedicated server, a Helm chart, or a database as a service from a cloud provider. Dependencies may also be resolved to existing installations of bundles, such as a shared dev database or a redis instance for the staging environment.

This allows better reuse of bundles, so that a bundle author can write a bundle for just their software, and they don’t need to write cloud provider specific bundles, such as “my software on Azure”, “my software on Amazon”, etc. Instead, they can create a bundle that requires another bundle that matches a specified interface and Porter can satisfy that dependency differently depending on the target environment.

Development is already in-progress and a lot of initial groundwork in the form of spec changes and refactoring has already been merged into main to support the next version of dependencies.

Improved Bundle Security

Mixins are wrappers around common deployment tools, such as Terraform and Helm, that make it easier to use that tool inside a bundle with Porter. Currently, they are distributed as binaries, and embedded inside the bundle’s image.

We want to improve bundle security by distributing and executing mixins as bundles, essentially decomposing bundles into smaller bundles that we can more securely distribute and execute (PEP005). This has a number of advantages such as:

Secure distribution mechanism of mixins. This allows us to no longer need to “install” mixins, or trust those installed mixins. Bundles can reference mixins from OCI registries and take advantage of existing security tooling and software to distribute, scan, and sign mixins.
Isolate credentials used by a bundle to just the relevant portions of the bundle. For example, only the Azure mixin should have access to your Azure credentials, and only the Helm mixin should have access to your kubeconfig. Credentials applicable to one mixin are not exposed to other unrelated mixins or scripts in the bundle.
Achieve significant performance improvements due to improved reuse of cached image layers.

All these features rely upon the Advanced Dependencies feature, so these will be delivered after that work is completed.

Signing and SBOMs

There have been huge leaps forward in the world of signing and software bills of material (SBOMs) in the past year, and we’re ready to take advantage of these new developments. New versions of the OCI Distribution spec, alternatives to Notary such as cosign, and a plethora of SBOM generating libraries are available for us to build into Porter.

Our plan is to incrementally add features allowing you to:

Sign bundles
Distribute the bundle signature when the bundle is published
Validate a bundle signature
Generate a software bill of materials for possibly multiple aspects of a bundle: the bundle itself, the mixins and tools used in the bundle, and of course the software deployed by the bundle.

We plan to build support for these features incrementally throughout the year, so you won’t see everything get rolled out at once in a big bang release.

Contributors Welcome!

Phew! This is a big chunk of work for a pretty small group of maintainers and contributors. So if you find any of this interesting, please consider helping us out!

Our Contributing landing page has details on how to get involved with the project. We welcome all types of contributions, such as:

Feedback on use cases and requirements
Testing out early releases of features
Reviews of our designs and proposals
Saying hi in meetings and reminding us that someone cares about any of this shipping
Happy emoji reactions on our slack announcements and progress reports

This is going to be a big year, and we hope you come along for the ride!

Quickly set up a Porter environment with required plugins

Tue, 24 Jan 2023 00:00:00 +0000

Breaking change

The recent porter v1.0.5 release introduced a new flag --file on porter plugins install command. Its intention is to allow users to install multiple plugins through a plugins definition file with a single porter command. However, it did not work as expected due to bad file format.

The fix that contains the correct schema has been published with a new v1.0.6 release. If you have an existing plugins file, please update it to work with v1.0.6+.

Install multiple plugins with a single command

Now, you can install multiple plugins using a plugin definition yaml file like below:

schemaType: Plugins
schemaVersion: 1.0.0
plugins:
  azure:
    version: v1.0.1
  kubernetes:
    version: v1.0.1

After creating the file, you can run the command:

porter plugins install -f <path-to-the-file>

The output from the command should look like this:

installed azure plugin v1.0.1 (e361abc)
installed kubernetes plugin v1.0.1 (f01c944)

Make sure to update your current plugins schema file to the latest format Please let us know how the change went (good or bad), and we are happy to help if you have questions, or you would like help with your migration.

A more YAML friendly template delimiter

Tue, 26 Jul 2022 00:00:00 +0000

Porter is getting a different template delimiter in v1! Previously, the template delimiter used in porter.yaml was {{ }} and we are changing it to ${ } starting in v1.0.0-beta.2.

What does this change?

The problem with the old delimiter is that it forced all templates to be wrapped in quotes because curly braces are special characters in YAML. The quotes made it impossible to pass a boolean or numeric value to a mixin because the wrapping quotes always forced the value to be a string.

schemaVersion: 1.0.0
name: a-great-bundle

custom:
  aBool: true
  aNumber: 3.33
  aString: v1.2.3

install:
  - mymixin:
      aBool: "${ bundle.custom.aBool }" # renders as "true"
      aNumber: "${ bundle.custom.aNumber }" # renders as "3.33"
      aString: "${ bundle.custom.aString }" # renders as "v1.2.3"

The new delimiter, ${ }, works better when embedded in YAML and doesn’t require the use of quotes. Here is the same bundle with the new delimiter, and we can finally use booleans and numbers! 🎉

schemaVersion: 1.0.0
name: a-great-bundle

custom:
  aBool: true
  aNumber: 3.33
  aString: v1.2.3

install:
  - mymixin:
      aBool: ${ bundle.custom.aBool } # renders as true
      aNumber: ${ bundle.custom.aNumber } # renders as 3.33
      aString: ${ bundle.custom.aString } # renders as v1.2.3

What do you need to change?

If you do nothing, your bundles will continue to build. Porter will continue to support the old delimiter as long as your bundle is using schemaVersion 1.0.0-alpha.1.

If you want to use the improved delimiter, edit your porter.yaml, set your schemaVersion to 1.0.0 and use ${ } in your templates. Optionally, you can also remove the wrapping quotes around the templates.

We hope this is a welcome change and please send us feedback if you run into any trouble updating your templates!

Upgrade your plugins to securely store sensitive data

Tue, 31 May 2022 00:00:00 +0000

As Porter approaches a v1.0.0 release, we have made an improvement in Porter to make sure any sensitive data generated or referenced by Porter is stored in a secure location. The newly updated secret plugin protocol enables Porter to securely store sensitive data in an external secret store instead of in Porter’s database.

Previously Porter only uses plugins for retrieving secrets from a secret store. When it comes to storing data generated by bundles, Porter uses storage plugins like Mongo as its backend database solution. If sensitive data, such as a database connection string, were generated by a bundle, it would be stored in a Mongo database in plain text. Now Porter requires users to configure a secret store to hold any data that has been marked as sensitive by the bundle.

Let’s walk through how to utilize this new feature by updating your Porter configuration file and selecting an appropriate secret plugin.

First, install the latest Porter v1 prerelease.

Next, let’s install a bundle that handles sensitive data using just the default Porter configuration.

porter install --reference ghcr.io/getporter/examples/sensitive-data --param password=123a123

You should see below error message in the output from the above command:

failed to save sensitive param to secrete store: rpc error: code = Unknown desc = The default secrets plugin, secrets.porter.host, does not support persisting secrets: not implemented

The example bundle defines a sensitive parameter named as password and a sensitive output called name.

Porter’s default secret plugin does not persist sensitive data. Any bundle that references or produces sensitive data will fail to execute. We do this because there isn’t a clear set of safe defaults that are suitable for all users when it comes to storing sensitive data. Instead it is up to the user to select and configure an appropriate secrets plugin.

Now let’s configure Porter to persist sensitive data with the filesystem plugin.

default-secrets-plugin: "filesystem"

The filesystem plugin resolves and stores sensitive bundle parameters and outputs as plain-text files in your PORTER_HOME directory. Note: the filesystem plugin is only intended for testing and local development usage. It’s not intended to be used in production. The end of this blog post has recommended plugins that are suitable for production use.

Now you have a secret store set up, we can finally to install the example bundle, this time successfully.

porter install --reference ghcr.io/getporter/examples/sensitive-data --param password=123a123

Once the installation process finishes, you should see outputs like below:

executing install action from sensitive-data (installation: /sensitive-data)
Install Hello World
Hello, installing example-bundle with password: *******
execution completed successfully!

If you inspect Porter’s database, it stores a reference to the sensitive data that was saved in the configured secret store. Porter no longer stores the sensitive data in its database.

Instead, we can find our “password” in our filesystem plugin. In your PORTER_HOME directory, you should find a subdirectory named secrets. Each file under this directory contains the sensitive value corresponding to a sensitive parameter or sensitive output from a run of a bundle.

This is why it’s important to choose a secure secret plugin for your production environment so that your sensitive data is protected. As you can see, the filesystem plugin is only acceptable for local development and testing.

Here are some secret plugins that we recommend for production use:

Give them a try and let us know how it works for you! If there is a secret solution that you would like to use with Porter, let us know, and we can help make that happen more quickly.

Get those secrets out of your config

Tue, 01 Feb 2022 00:00:00 +0000

As part of the v1 hardening process, we have been hard at work securing Porter. Keeping sensitive data off your machine, and safely in a secret store or vault where it belongs is a big part of that. Now Porter’s config file is getting the same white glove treatment that bundle credentials always have! We have added templating support to Porter’s config file so that you can use environment variables and secrets without hard-coding sensitive data in the file.

Porter has plugins for retrieving secrets from a secret store, and for storing its data in a Mongo database. Configuring the plugins with credentials to connect to those resources is how sensitive data sneaks into the config file. Let’s walk through what your config file may look like today and how to take advantage of templating to keep your config file secret-free.

# ~/.porter/config.toml
default-storage = "mydb"

[[storage]]
  name = "mydb"
  plugin = "mongodb"

  [[storage.config]]
    url = "a top secret mongodb connection string"

[[secrets]]
  name = "mysecrets"
  plugin = "azure.keyvault"
  
  [[secrets.config]]
    vault = "myvault"
    subscription-id = "my azure subscription id"

In the example above we have two bits of sensitive data in the config file: a mongodb connection string, and our Azure subscription id. We can replace those hard-coded values with templates, using ${env.NAME} to insert an environment variable and ${secret.KEY} to resolve a secret from your default secret store. Below is the final, secret-free version of the same config file:

# ~/.porter/config.toml
default-storage = "mydb"

[[storage]]
  name = "mydb"
  plugin = "mongodb"

  [[storage.config]]
    url = "${secret.porter-connection-string}"

[[secrets]]
  name = "mysecrets"
  plugin = "azure.keyvault"
  
  [[secrets.config]]
    vault = "myvault"
    subscription-id = "${env.AZURE_SUBSCRIPTION_ID}"

Porter takes two passes over the configuration file: first replacing environment variables, and then resolving any secrets used in the config file with the secrets plugin.

You may have noticed that this is a different template syntax than what is used in porter.yaml. In an upcoming release, Porter’s template syntax will get a similar refresh, so that the templating language is the same for both Porter’s manifest and its configuration file.

Install the latest v1 prerelease and make your config files secret-free! 🕊

Ignoring Mixin Errors and Idempotent Actions

Tue, 25 Jan 2022 00:00:00 +0000

Previously, if you needed to handle an error in a bundle, you had to switch from Porter’s declarative mixin syntax to a bash script. But not anymore! The exec mixin has just added support for determining if the error returned by a command is fatal, and should stop the bundle, or if the error can be ignored.

A common scenario for ignoring errors is during the install action. When an install fails halfway through, the user will try again by repeating the install command. If a resource was created during the first install, repeating a command that creates a resource could result in an error because the resource already exists. Some command-line tools handle this gracefully, while others return an error. The exec mixin now lets you decide if that error is fatal based on the command’s return code or output.

Let’s take a look at a few different ways that you can handle errors from the exec mixin.

Ignore All Errors

You can ignore all errors that are returned by a command, and continue executing the next step in the action. This can be useful in a couple scenarios such as debugging while writing a bundle, when a command always returns a non-zero exit code, or when you want to try calling a command and keep going regardless of whether it worked.

install:
  - exec:
      description: "This may not work but such is life"
      command: ./buy-me-coffee.sh
      ignoreError:
        all: true # Ignore any errors from this command

Ignore Exit Codes

Sometimes you get lucky, and the command that you are using has well-defined exit codes. For the following example, the behavior of thing responds with the exit code [2] when the resource already exists.

install:
  - exec:
      description: "Ensure thing exists"
      command: thing
      arguments:
        - create
      ignoreError:
        exitCodes: [2]

In this example, since you don’t care about the implied error as the desired outcome is the existence of resource, you configure porter to ignore the [2] exit code.

You can ignore multiple exit codes, and if any match, then the command’s error is ignored.

Ignore Output Containing a String

Usually we aren’t so lucky, and we have to scrape the contents of standard error to figure out what went wrong. Continuing our efforts to create idempotent resources, we can ignore the error when it contains “thing already exits”.

install:
  - exec:
      description: "Ensure thing exists"
      command: thing
      arguments:
        - create
      ignoreError:
        output:
          contains: ["thing already exists"]

Ignore Output Matching a Regular Expression

Finally, there are times when the error message is a bit more difficult to parse, so we fall back to our favorite hammer: regular expressions. In the example below, when we delete a thing that has already been deleted, “thing NAME not found” is printed to standard error.

Regular expressions being the tricky devils they are, I recommend using regex101.com to quickly test and iterate on your regular expression.

uninstall:
  - exec:
      description: "Make the thing go away"
      command: thing
      arguments:
        - remove
      ignoreError:
        output:
          regex: "thing (.*) not found"

Create Custom Idempotent Mixin Commands

Whenever possible, I encourage you to avoid the exec mixin and use a custom mixin for the tooling that you are automating. For example, if you are automating terraform, use the terraform mixin. Mixins are meant to adapt a tool to work well inside a bundle.

I used the new ignore errors capability of the exec mixin’s library to create a custom command for the az mixin. The group command allows you to declare a resource group, and the mixin will handle creating it if it doesn’t exist, and cleaning it up when the bundle is uninstalled.

install:
  - az:
      description: "Ensure my resource group exists"
      group:
        name: mygroup
        location: eastus2

uninstall:
  - az:
      description: "Remove my resource group"
      group:
        name: mygroup

These mixin commands are idempotent and handle errors automatically for you. This lets you focus on the resources you need, and spend less time figuring out how to automate a command-line tool to work in a way it wasn’t designed for.

Try it out

Bundle authors, try moving some of that custom error handling logic out of bash scripts and into your exec mixin calls. Mixin authors, take a look at how the Skeletor mixin template source uses the get.porter.sh/porter/pkg/exec/builder package to include error handling. You can quickly add the same error handling behavior to your mixin, or create a custom command that handles errors automatically by looking at the source for the az group command.

Give it a try and let us know how it works for you! If there is a mixin that you would like to use this new error handling with, let us know, and we can help make that happen more quickly.

Helm3 Mixin Improvements

Tue, 28 Sep 2021 00:00:00 +0000

If you use Helm in your bundles, then you are going to want the latest helm3 mixin release! With improved defaults, and new flags supported, the helm3 v0.1.15 mixin will help make your bundles more reliable.

If you are still using the deprecated helm mixin, now’s the time to switch over to Mohamed Chorfa’s Helm3 mixin.

New Defaults

The helm3 mixin has changed its default behavior to be more robust and avoid situations where the mixin fails when an action is retried.

Upgrade or Install

The upsert setting has been removed because it is now the default behavior for the install and upgrade actions. Now the mixin always uses helm upgrade --install which improves reliability when you need to retry a failed action.

Create Namespace

The mixin specifies --create-namespace by default so that the release namespaces is created automatically when it is not already present.

Atomic

The --atomic flag is now specified by default, failed helm releases are rolled back so that your release is always in a working state.

New Settings

The helm3 mixin now supports additional Helm flags:

The noHooks setting prevents hooks from being executed and defaults to false.
The skipCrds setting skips installing CRDs during upgrade. By default, CRDs are installed if not already present.
The timeout setting sets how long Helm will wait for the release to complete successfully before rolling it back (due to the atomic behavior).
The debug setting gives you more insight into why a release failed and was rolled back.

Removed Settings

The upsert setting has been removed because it is the default behavior.
The replace setting has been removed because it is not recommended for production use, and shouldn’t be necessary with the new default behavior.

The Porter project has already upgraded our bundles to use this latest version, and I recommend upgrading your bundles to take advantage of the improved reliability. The only hiccup in our upgrade was that the --atomic behavior made us quickly realize that some of our charts were never actually installing 100% successfully. 🤦‍♀️ If you have charts that don’t work well with --atomic or --wait, or need additional flags exposed, let us know!

1.0.0-alpha.3 is here!

Tue, 21 Sep 2021 00:00:00 +0000

Check out the new features introduced in Porter v1.0.0-alpha.3 such as MongoDB, namespaces, bundle state and credential import.

This is a big release for our v1 alpha with LOTS of major changes that we hope make Porter easier to use such as MongoDB, namespaces, labels, bundle state, and credential import. Our release notes have a full accounting of all fifty-eight pull requests that were included in this release.

A v1 version of our documentation is available at https://porter.sh.

Breaking Changes

Safety first! In this release we have removed support for deprecated flags such as –tag and fields like tag in porter.yaml. If you have been ignoring a warning message in Porter’s output for months, now is the time to fix those messages before upgrading.

MongoDB Support

Porter now stores its data in MongoDB! We no longer store installation records on the filesystem, though we still do have a ~/.porter directory with our configuration and cache. In dev and test, Porter by default runs MongoDB in a container for you on port 27018 and connects to it. The mongodb-docker plugin stores the underlying mongo data in a Docker volume, but persistence is not guaranteed which is why this is only for non-production environments. Once Porter v1 is ready for production, the mongodb storage plugin is what you should use to connect to an existing MongoDB server.

default-storage = "mydb"

[[storage]]
  name = "mydb"
  plugin = "mongodb"

  [storage.config]
    url = "mongodb://username:password@host:port"

CosmosDB works as well, though we have a known performance problem with our CosmosDB indices that will be addressed in the next release.

Any existing v0.38 compatible storage mixins, such as the azure storage plugin, do not work with this release. We are still finalizing the new storage plugin protocol, so we suggest holding off on making a custom storage plugin until its ready.

Namespaces

Porter resources such as installations, credential sets and parameter sets can optionally be defined within a namespace. Resources that are not defined in a namespace are considered global. When an installation is defined in a namespace, it can reference a credential or parameter set that is also defined in that namespace or at the global scope. Resources defined globally cannot reference other resources that are defined in a namespace.

You can set the current namespace in the Porter configuration file using the namespace setting.

When an installation references a parameter or credential set, Porter first looks for a resource with that name in the current namespace. If one does not exist, Porter then looks for that resource at the global level. This lets you define a common set of credentials to be used for an environment, like staging environment credentials that everyone can reuse, while allowing for overriding that resource within a particular namespace.

# list just in the current namespace defined in your porter config
porter installations list

# list in the specified namespace
porter installation list --namespace myuser

# list across all namespaces
porter installation list --all-namespaces

# list across all namespaces (alternate syntax)
porter installation list --namespace '*'

Labels

Porter resources also now support labels which may be used for filtering with the list commands. For example:

porter installations list --label env=dev --label app=myapp
porter credentials list --label env=dev
porter parameters list --label env=dev

Bundle State

Bundle authors can now declare that certain files are “state” and should be preserved between bundle runs. A prime example is the tfstate and tfvars files created by the terraform mixin. Now instead of using the old method of declaring those files as both parameters and outputs, you should declare them as state and Porter will ensure that they are always available to your bundle.

This corrects the problem encountered by installations using the terraform mixin wherein resources created by terraform were not recorded and reused after a failed install, leaving it up to the user to manually clean up resources.

Import credentials and parameter sets

Use the apply command to import a credential or parameter set from a file.

porter credentials apply mycreds.yaml
porter parameters apply myparams.json

You can export a credential or parameter set to a file with the show command.

porter credentials show mycreds --output yaml > mycreds.yaml
porter parameters show myparams --output json > myparams.json

Install the v1 Prerelease

We would love for you to try out v1.0.0-alpha.3 and send us any feedback that you have! Keep in mind that the v1 prerelease is not suitable for running with production workloads, and that data migrations will not be provided or supported for v1 prereleases. The prerelease is intended for you to try out the new features in Porter, and provide feedback but won’t work with existing installations.

One way to try out Porter without messing with your current installation of Porter is to install Porter into a different PORTER_HOME directory.

MacOS

export PORTER_HOME=~/.porterv1
export VERSION="v1.0.0-alpha.3"
curl -L https://cdn.porter.sh/$VERSION/install-mac.sh | bash

Linux

PORTER_HOME=~/.porterv1
VERSION="v1.0.0-alpha.3"
curl -L https://cdn.porter.sh/$VERSION/install-linux.sh | bash

Windows

$PORTER_HOME="$env:USERPROFILE\.porterv1"
$VERSION="v1.0.0-alpha.3"
(New-Object System.Net.WebClient).DownloadFile("https://cdn.porter.sh/$VERSION/install-windows.ps1", "install-porter.ps1")
.\install-porter.ps1 -PORTER_HOME $PORTER_HOME

Now when you want to use the v1 version of Porter, set the PORTER_HOME environment variable and add it to your PATH.

Posix Shells

export PORTER_HOME=~/.porterv1
export PATH="$PORTER_HOME:$PATH"

PowerShell

$env:PORTER_HOME="$env:USERPROFILE\.porterv1"
$env:PATH+=";$env:PORTER_HOME"

Upgrade to the helm3 mixin

Thu, 01 Jul 2021 00:00:00 +0000

The time has come… to upgrade to the helm3 mixin.

Last year Helm v2 was put on ice and all new development and support going forward has been happening on Helm v3. The helm mixin was developed before Helm v3 and only supports Helm v2, so the time has come for us all to say goodbye to helm mixin and upgrade to the helm3 mixin.

Luckily for us Mohamed Chorfa maintains the helm3 mixin and that is the recommended mixin to use going forward. If you have previously installed the helm mixin with porter mixins install helm the new command is:

porter mixin install helm3 --feed-url https://mchorfa.github.io/porter-helm3/atom.xml

The old helm mixin has been deprecated and renamed to helm2 to avoid confusion. The helm mixin will no longer appear in mixin search results, although you can still explicitly install it.

So please upgrade to the helm3 mixin if you haven’t already. And as always let us know if you run into any problems or have feedback!

Porter v1 on the Horizon

Tue, 11 May 2021 00:00:00 +0000

Like a farmer asking “when it’s gonna rain?”, I am often asked “when you gonna ship v1?”

The Porter maintainers have tweaked our goals for v1. Mainly to stop chasing feature complete and ship a stable version of what works today. Our v1 milestone focuses on P0 and P1 bugs (informally known as emergency donuts 🚨🍩 and chocolate 🍫 in our issue backlog), usability issues without good workarounds, and batching together breaking changes.

Over the course of Porter’s lifetime we have deprecated some configuration and flags, but kept shims in place for those who haven’t migrated to the replacements yet. For example --tag was replaced by --reference, but we still support --tag for now. In v1 those deprecation shims will be removed, and anyone who hasn’t migrated yet will need to update their scripts and porter.yaml files.

In order to isolate you from those changes, we have created a v1 branch where all v1 work will be batched up. Our version strategy outlines our development process while we work on v1 and what to expect in terms of version numbers and stability. No breaking changes will be released going forward until we ship the final v1.0.0 release of Porter. We will be cutting pre-release versions of Porter that you may test out and prepare for v1.

The canary and latest releases will continue to follow the stable main branch. We recommend that you stick with latest, or even better a pinned version of Porter, until v1.0.0 is available. That way you are isolated from breaking changes until you are ready to upgrade.

Don’t worry, we are still improving Porter! New features, such as buildkit support, advanced dependency management, organization with labels and namespaces, and more are still under development. They will be released as experimental features that are disabled by default with feature flags. That way we can keep Porter stable, and give you a way to try out new functionality and provide feedback before they are completed.

This is open source, and we only get things done as quickly as we have consensus and contributors. While I can’t give a concrete timeline, we would love to see a v1 release this summer. We always welcome new contributors, even if you are new to Go, containers, or even Porter! If you’d like to help us with v1 or contribute to the larger features in our pipeline, the new contributor guide is where to start. 🚀

Migrate from Docker App to Porter

Wed, 05 May 2021 00:00:00 +0000

Welcome Docker App users! 🎉 Docker recently announced that they are no longer developing Docker App, and that you should migrate to Porter to continue using your app (bundle) and work with it like you do today. Let’s walk through how to migrate your Docker App to Porter.

Docker App under the hood has always created and deployed Cloud Native Application Bundles, though you may not have realized it. Porter also supports creating bundles, publishing them to OCI registries, and managing the application lifecycle with install, upgrade and uninstall commands.

Porter uses mixins to compose bundles using existing tools, such as docker-compose, helm, or terraform. We will use the docker-compose mixin to migrate an existing Docker App to Porter.

Install Porter.
Install the docker-compose mixin by running porter mixins install docker-compose.

Create a porter.yaml file in the same directory as your docker app next to the docker-compose.yaml. Copy into porter.yaml the contents below.

schemaVersion: 1.0.0-alpha.1
name: examples/dockerapp
version: 0.2.0
description: "An example bundle that demonstrates how to move from Docker App to Porter"
registry: ghcr.io/getporter

required:
- docker:
    privileged: false # Change to true if you need privileged containers

parameters:
- name: hello_text
  type: string
  env: hello_text
  default: hello from porter
- name: hello_port
  type: integer
  env: hello_port
  default: 8080
- name: context
  type: string
  default: default

mixins:
- docker-compose

install:
- docker-compose:
    arguments:
    - up
    - -d

upgrade:
- docker-compose:
    arguments:
    - up
    - -d

uninstall:
- docker-compose:
    arguments:
    - down

Open metadata.yaml from your docker app.

version: 0.1.0
name: my-docker-app
description: My amazing docker app
maintainers:
  - name: Maria Gomez
    email: mariagomez@example.com

Open porter.yaml and copy the version, name, and description values into porter.yaml into the corresponding fields. Porter doesn’t have a field for maintainers, so that doesn’t need to be migrated.
```
name: my-docker-app
version: 0.1.0
description: My amazing docker app
```
Open your parameters.yaml. Add each parameter to porter’s parameters field. If your parameter used a period or other characters that are not allowed in an environment variable name, replace that character with an acceptable substitute such as underscore _. Update your docker-compose.yaml to use any of the newly renamed parameters.

parameters.yaml
```
hello:
  text: hello from porter
  porter: 8080
```
porter.yaml
```
parameters:
- name: hello_text
  type: string
  env: hello_text
  default: hello from porter
- name: hello_port
  type: integer
  env: hello_port
  default: 8080
```

Install the bundle with porter install --allow-docker-host-access. The --allow-docker-host-access flag is required so that the bundle can communicate with the docker host.

Porter supports the DOCKER_HOST and DOCKER_CONTEXT environment variables. You can use these to have Porter deploy your application to a remote host.

$ porter install --allow-docker-host-access
installing my-docker-app...
executing install action from my-docker-app (installation: my-docker-app)
/usr/local/lib/python3.5/dist-packages/paramiko/transport.py:33: CryptographyDeprecationWarning: Python 3.5 support will be dropped in the next release of cryptography. Please upgrade your Python.
  from cryptography.hazmat.backends import default_backend
Creating app_hello_1 ... done
execution completed successfully!

Confirm that your application was deploy with docker ps.

$ docker ps
CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS          PORTS                                       NAMES
c5428e359333   hashicorp/http-echo   "/http-echo -text 'h…"   27 minutes ago   Up 27 minutes   0.0.0.0:8080->5678/tcp, :::8080->5678/tcp   app_hello_1

You can view your installations with porter list:

$ porter list
NAME                 CREATED          MODIFIED         LAST ACTION   LAST STATUS
my-docker-app        28 minutes ago   28 minutes ago   install       succeeded

Let’s look at the details of your migrated application with porter show. The output tells us that it was installed successfully and shows the history of changes made to the installation.

$ porter show my-docker-app
Name: my-docker-app
Created: 28 minutes ago
Modified: 28 minutes ago

Outputs:
-------------------------------------------------------------------------------
  Name                                 Type    Value
-------------------------------------------------------------------------------
  io.cnab.outputs.invocationImageLogs  string  executing install action from
                                              my-docker-app (installation...

History:
----------------------------------------------------------------------------
  Run ID                      Action   Timestamp       Status     Has Logs
----------------------------------------------------------------------------
  01F4YMH7AETP2P38Y81YVQ5TJS  install  28 minutes ago  succeeded  true

So far we have been working inside the “developer iteration loop”, where you can edit the bundle on your local filesystem and deploy it to your developer environment to test it. Once the bundle is stable, the next step is to publish it to an OCI registry so that others can install your bundle using its reference. All of the porter commands accept a flag, --reference, for example porter install --reference ghcr.io/getporter/examples/porter-hello:v0.2 so that you do not need to distribute the bundle files themselves.
When you are ready to share your bundle with others, select which OCI registry where you will host the bundle, for example, ghcr.io/getporter or on Docker Hub under your username carolynvs. Edit your porter.yaml and set the registry field to the destination registry.
```
name: my-docker-app
version: 0.1.0
description: My amazing docker app
registry: carolynvs
```

Publish your bundle to the destination registry with porter publish.

$ porter publish
Pushing CNAB bundle image...
The push refers to repository [docker.io/carolynvs/my-docker-app-installer]
a5fd17ef8522: Preparing
878a51fed4d7: Preparing
d774d6a15e77: Preparing
5ff217bf43f5: Preparing
739733239466: Preparing
d7b369a46116: Preparing
356db0d0a1d7: Preparing
d7b369a46116: Waiting
356db0d0a1d7: Waiting
878a51fed4d7: Pushed
d774d6a15e77: Pushed
356db0d0a1d7: Mounted from library/debian
d7b369a46116: Pushed
a5fd17ef8522: Pushed
5ff217bf43f5: Pushed
739733239466: Pushed
v0.1.0: digest: sha256:b3e56730d60e1f587ba34f4316bc20b22a7f8b1daf13560bf91d67a72b858243 size: 1792

Rewriting CNAB bundle.json...
Starting to copy image carolynvs/my-docker-app-installer:v0.1.0...
Completed image carolynvs/my-docker-app-installer:v0.1.0 copy
Bundle tag docker.io/carolynvs/my-docker-app:v0.1.0 pushed successfully, with digest "sha256:5631fb62f7fbf3fa7c54fe640808045bd3a7de9cfd691645c48c929398f31e92"

The last line of the output prints the full reference to the published bundle, in this case docker.io/carolynvs/my-docker-app:v0.1.0. You can use or omit the docker.io registry depending on your preference.

Now that your bundle is published, let’s install it. First change your current directory in your terminal to leave the directory containing your bundle’s source code. We are going to install the bundle again, this time using the published bundle.

Replace YOUR_BUNDLE_TAG with the reference printed by porter publish. We will use the installation name my-app to reference the installation in subsequent commands.
```
$ porter install my-app --reference YOUR_BUNDLE_REFERENCE
```
For example,
```
$ porter install my-app --reference carolynvs/my-docker-app:v0.1.0
```
Oops! You made a mistake in your original bundle and need to fix it. Open your porter.yaml file and increase the version number.
```
version: 0.1.1
```
Rebuild the bundle and publish the new version.
```
porter build
porter publish
```
You can use porter upgrade to upgrade the installation to the latest version, specifying the newly published version of your bundle.
```
$ porter upgrade my-app --reference YOUR_UPDATED_BUNDLE_REFERENCE --allow-docker-host-access
```
For example:
```
$ porter upgrade my-app --reference carolynvs/my-docker-app:v0.1.1 --allow-docker-host-access
```
You can configure Porter to always allow Docker host access so that you do not need to set it with a flag on every command.
Once you are done, uninstall the bundle with porter uninstall.
```
porter uninstall my-app
```

Hopefully the migration process isn’t too complicated! We would love to have you migrate your Docker App to Porter and continue to use CNAB and bundles to manage your applications. Please let us know how the migration went (good or bad), and we are happy to help if you have questions, or you would like help with your migration.

View Logs From Previous Runs

Mon, 22 Mar 2021 00:00:00 +0000

With the v0.35.0 release of Porter, the logs generated when install/upgrade/invoke/uninstall is run are persisted. Now you can view logs from previous runs, which can come in handy when troubleshooting a deployment.

You can view the logs from the most recent execution of a bundle with the porter logs command:

$ porter logs -i whalegap
executing install action from whalegap (installation: whalegap)
Install WhaleGap
/usr/local/bin/helm helm install --name whalegap ./charts/whalegap --replace --set image.digest=sha256:5cca9dfa8ba540a32537d586651d3918d6f39761cdf4457fbe32c58c36c1defc --set image.repository=carolynvs/trust-demo --set msg=whale hello there!
NAME:   whalegap
LAST DEPLOYED: Tue Mar  9 16:43:15 2021
NAMESPACE: porter-operator-system
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME      READY  UP-TO-DATE  AVAILABLE  AGE
whalegap  0/1    1           0          0s

==> v1/Pod(related)
NAME                       READY  STATUS             RESTARTS  AGE
whalegap-76b77b9f99-6ww22  0/1    ContainerCreating  0         0s

==> v1/Service
NAME      TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)  AGE
whalegap  ClusterIP  10.108.26.188  <none>       80/TCP   0s

==> v1/ServiceAccount
NAME      SECRETS  AGE
whalegap  1        0s


NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace porter-operator-system -l "app.kubernetes.io/name=whalegap,app.kubernetes.io/instance=whalegap" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:80

execution completed successfully!

We have changed the output of the porter show command to provide IDs for previous executions of a bundle:

$ porter show whalegap
Name: whalegap
Created: 2021-01-27
Modified: 2021-03-09

Outputs:
-------------------------------------------------------------------------------
  Name                                 Type    Value
-------------------------------------------------------------------------------
  io.cnab.outputs.invocationImageLogs  string  executing install action from
                                               whalegap (installation: wha...

History:
--------------------------------------------------------------------------
  Run ID                      Action     Timestamp   Status     Has Logs
--------------------------------------------------------------------------
  01EX0JS7JX8K2A4JQ8NAABVBDZ  install    2021-01-27  succeeded  false
  01F0BXXXE9MSJZRMW0M95V4DF9  install    2021-03-09  succeeded  true

In the output above, we can see that I first tried to install a bundle and it failed. Since it was executed with a version of Porter older than v0.35.0, no logs are available. Then I reinstalled the bundle using the latest version of Porter, and luckily this time it succeeded, and the logs were persisted.

You can view the logs from a specific run using the --run flag, which is really useful when you are figuring out how to capture text output when the bundle was run, or comparing a good/bad run to figure out what went wrong.

porter logs --run 01F0BXXXE9MSJZRMW0M95V4DF9

Happy logging! 🔎

Set Bundle Metadata on Build and Publish

Thu, 14 Jan 2021 00:00:00 +0000

With the v0.31.0 release of Porter you can now quickly set metadata on your bundle. This corrects confusing terms around the OCI reference of the bundle (the location of a bundle in a registry).

reference = registry/name:tag

Reference: A bundle reference is the location of a published bundle. For example, ghcr.io/getporter/porter/porter-hello:v0.1.1. Previously this was called bundle tag.

Until we release v1.0, Porter detects when you use the flags with the old meanings and fixes it for you. When Porter releases v1.0, that behavior will be removed.
Registry: The location prefix of a published bundle. For example, with ghcr.io/getporter/porter/porter-hello:v0.1.1 the registry is ghcr.io/getporter/porter.
Tag: Tag now only means the OCI artifact tag, which is the last part of a bundle or image reference after the colon. For example, with ghcr.io/getporter/porter-hello:v0.2.0 the tag is v0.2.0. Previously this had two definitions: bundle tag and OCI artifact tag.

Build Workflow

You can change the bundle name and version when building the bundle. Porter replaces the specified field in porter.yaml in-memory with the new value before building the bundle. The porter.yaml file is not modified.

Name

Set the bundle name with --name when building the bundle:

porter build --name porter-hello

Version

Set the bundle version with --version when building the bundle:

porter build --version v0.1.1

Most bundle pipelines will determine the version on the fly during the build either from application version or using git tags.

Publish Workflow

You can change where the bundle is published using the flags below, and Porter will retag the bundle before pushing it.

Tag

Set the tag with --tag when publishing the bundle:

porter publish --tag latest

We don’t recommend using mutable tags like latest in production, but they are very useful during development and test.

Registry

Set the registry with --registry when publishing the bundle:

porter publish --registry ghcr.io/getporter

This makes it easier to publish a bundle to multiple registries, for example both Docker Hub and GitHub Container Registry, at the same time.

Reference

Set the entire reference with --reference when publishing the bundle:

porter publish --reference localhost:5000/testing/hello:dev

Using a combination of the build and publish flags works for most CI/CD scenarios. If for some reason the other flags don’t work for your situation, you can override the entire reference, bypassing Porter’s defaulting logic.

Hopefully makes it a lot easier to build and publish a bundle in your CI pipeline. Try it out and let us know how it works for you!

Porter Has Joined the CNCF as a Sandbox Project

Mon, 28 Sep 2020 00:00:00 +0000

When Jeremy Rickard and I created Porter less than two years ago, we wanted to create a community-led project that would encourage collaboration across vendors to make Cloud Native Application Bundles (CNAB) accessible and maintainable. We want to continue to support that mission of vendor neutral independence while growing the community of practitioners who can use and contribute to Porter’s development.

Today, the Porter Maintainers are happy to announce that Porter has been accepted as a CNCF Sandbox project. By contributing Porter to the CNCF, we hope to encourage the adoption of Porter to ease the creation and use of bundles and to see more companies contribute mixins.

In the near-term, we are focusing on our roadmap. Our introductory documentation will be expanded and restructured to make it easier to get started with Porter and bundles. We have also been collecting feedback from the community on various usability points in Porter, for example how to build and promote bundles in a CI pipeline or use template variables in the Porter manifest, and we will begin addressing these items to make Porter easier to use and automate.

In addition to contributing ideas and energy to those initiatives, developers can contribute mixins by following our Mixin Development Guide. Examples of mixins include the Docker Mixin and Terraform Mixin.

If you are interested in learning more about bundles, check out this introductory video. Learn more about the Porter Community and contribute to the project.

Docker Mixin for Porter!

Tue, 28 Jul 2020 00:00:00 +0000

We are excited to announce the first release of a Docker mixin for Porter! 🐳

Mixins are critical building blocks for bundles, and we hope the Docker mixin will help ease the process of composing bundles. The Docker mixin installs Docker and provides the Docker CLI within bundles. Prior to the creation of this mixin, in order to use Docker within your bundle, you would have to create a custom Dockerfile and install Docker. Then, to run any Docker commands, you would need to use the exec mixin and call a bash script to execute the Docker commands.

The Docker mixin abstracts this logic for you and allows you to specify the Docker commands with the arguments and flags that you want to execute directly in the Porter manifest. The commands currently provided by the Docker mixin are pull, push, run, build, login, and remove. To view all the syntax for the commands, take a look at the README.

Let’s go through an example bundle to try out the mixin. First, we will use the Docker mixin to pull and run ghcr.io/getporter/examples/images/whalesay. Then, we will write our own Dockerfile, build it, and push it to Docker Hub.

Author the bundle

Writing a bundle with the Docker mixin has a few steps:

Let’s run through these steps with our example bundle called docker-mixin-practice. First, set up a project:

mkdir docker-mixin-practice;
cd docker-mixin-practice;

Create a bundle

Next, use the porter create command to generate a skeleton bundle that you can modify as we go through our example.

$ porter create

Install the Docker mixin

Next, you need to install the Docker mixin to extend the Porter client. To install the mixin, run the line below and you should see the output that it was installed.

$ porter mixins install docker

installed docker mixin v0.1.0 (b660770)

This installs the docker mixin into porter, by default in ~/.porter/mixins.

Add the Docker mixin to the Porter manifest

In order to use the Docker mixin within your bundle, you need to add it to the mixin list. In the create a bundle step, porter create added the exec mixin. Replace the exec line with docker.

mixins:
- docker

Use Docker CLI

Next, delete the install, upgrade, and uninstall actions. Now, to run ghcr.io/getporter/examples/images/whalesay, copy and paste the code below into the porter.yaml to pull the image and then run it with a command to say “Hello World”.

install:
- docker:
    description: "Install Whalesay"
    pull:
      name: ghcr.io/getporter/examples/images/whalesay
      tag: latest
- docker:
    description: "Run Whalesay"
    run:
      name: dockermixin
      image: "ghcr.io/getporter/examples/images/whalesay:latest"
      command: cowsay
      arguments:
        - "Hello World"

uninstall:
- docker:
    description: "Remove dockermixin container"
    remove:
      container: dockermixin

When you are ready to install your bundle, run the command below to install and give access to the Docker Daemon.

$ porter install demo --allow-docker-host-access

This is the output that should be generated after it runs.

Run Whalesay
 _____________ 
< Hello World >
 ------------- 
    \
     \
      \     
                    ##        .            
              ## ## ##       ==            
           ## ## ## ##      ===            
       /""""""""""""""""___/ ===        
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~   
       \______ o          __/            
        \    \        __/             
          \____\______/

Now, we will go through an example of how you can incorporate and build your own Docker image and then push it to Docker hub. First, you will need to create a Dockerfile named Dockerfile-cookies next to your porter.yaml and copy paste the code below into the file.

FROM debian:stable-slim

CMD ["echo", "Everyone loves cookies"]

To build an image from this Dockerfile, copy and paste the code below and replace the current install action. This will build your image, login to Docker, and push your image to a registry.

Change YOURNAME to your docker username.

install:
- docker:
    description: "Build image"
    build:
      tag: "YOURNAME/cookies:v1.0"
      file: Dockerfile-cookies
- docker:
    description: "Login to docker"
    login:
- docker:
    description: "Push image"
    push:
      name: YOURNAME/cookies
      tag: v1.0

Set up credentials

This step is needed if you wish to use Docker push to push an image to a registry. In order to push to one of your registries, you need to login to Docker Hub. To set up your credentials to login to Docker Hub, make sure the environment variables DOCKER_USERNAME and DOCKER_PASSWORD are set on your machine. Next, add these lines in your porter.yaml. You may change the name to what you want it to be.

credentials:
  - name: DOCKER_USERNAME
    env: DOCKER_USERNAME
  - name: DOCKER_PASSWORD
    env: DOCKER_PASSWORD

Next, run the following commands and edit the file with where the credentials will come from.

$ porter credentials create docker.json
$ cat docker.json
# modify docker.json with your editor to the content below
{
    "schemaType": "CredentialSet",
    "schemaVersion": "1.0.1",
    "name": "docker",
    "credentials": [
        {
            "name": "DOCKER_USERNAME",
            "source": {
                "env": "DOCKER_USERNAME"
            }
        },
        {
            "name": "DOCKER_PASSWORD",
            "source": {
                "env": "DOCKER_PASSWORD"
            }
        }
    ]
}
$ porter credentials apply docker.json

Your credentials are now set up. When you run install or upgrade or uninstall, you need to pass in your credentials using the -c or --credential-set flag.

When you are ready to install your bundle, run the command below to identify the credentials and give access to the Docker daemon.

$ porter install demo -c docker --allow-docker-host-access

After it runs, you should see output that the image was built and tagged successfully, the login succeeded, and the push to your repository happened.

Build image
Sending build context to Docker daemon  101.2MB
Step 1/2 : FROM debian:stable-slim
 ---> 614bb74b620e
Step 2/2 : CMD ["echo", "Everyone loves cookies"]
 ---> Using cache
 ---> e89d85933cc1
Successfully built e89d85933cc1
Successfully tagged *******/cookies:v1.0
Login to docker
Login Succeeded
Push image
The push refers to repository [docker.io/*******/cookies]
6885f9305c0a: Preparing
6885f9305c0a: Layer already exists
v1.0: digest: sha256:1fb89bd28f81c3e29ae16a44f077f4709f33ac410581faf23b42d9bd7a6f913b size: 529
execution completed successfully!

Finally, run the following command to clean everything up:

$ porter uninstall demo -c docker --allow-docker-host-access

Thank you for reading!

Please try out the mixin and let us know if you have any feedback to make it better! You can dig into the code here and create an issue here.

Using Docker inside Porter Bundles

Thu, 23 Apr 2020 00:00:00 +0000

Sometimes you need a hammer, and that hammer happens to be a whale 🐳. We all use containers as part of our pipeline: building images, running a one-off command in a utility container, spinning up a test environment to verify your application, or even more creative tasks that you have already containerized. Well now you can reuse all that hard work and logic from within your bundles!

Let’s walk through using my favorite container, ghcr.io/getporter/examples/images/whalesay, in a bundle.

 _____________________
< Challenge Accepted! >
 ---------------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/

Author the bundle

Writing a bundle that uses Docker has a few steps:

Here’s the full working example whalesay bundle for you to follow along with.

Require Docker

The user running the bundle, and Porter, needs to know that this bundle requires the local Docker daemon connected to the bundle. You need to a new section to porter.yaml for required extensions, and defined a new prototype extension that says that the bundle requires access to a Docker daemon:

required:
- docker

Optionally you can include that you also want the bundle to be run with --privileged which is intended for docker-in-docker scenarios:

required:
- docker:
    privileged: true

Install Docker

You can include the Docker CLI in your bundle by using the docker mixin.

mixins:
  - docker

You can then use the respective CLIs through the mixin:

install:
- docker:
    description: "Run my container"
    run:
      image: hello-world
      rm: true

This blog post focuses on just the docker mixin, but here is a full working example for how to use Docker Compose in a bundle.

Use Docker

In my porter.yaml, I can use the docker mixin to execute docker commands in my bundle:

porter.yaml

name: examples/whalesay
version: 0.2.0
description: "An example bundle that uses docker through the magic of whalespeak"
registry: ghcr.io/getporter

required:
  - docker

parameters:
  - name: msg
    description: a message for the whales to speak
    type: string
    default: "whale hello there!"
    applyTo:
      - say

mixins:
  - docker

install:
  - docker:
      run:
        image: "ghcr.io/getporter/examples/images/whalesay:latest"
        rm: true
        arguments:
          - cowsay
          - Hello World

upgrade:
  - docker:
      run:
        image: "ghcr.io/getporter/examples/images/whalesay:latest"
        rm: true
        arguments:
          - cowsay
          - World 2.0

say:
  - docker:
      run:
        image: "ghcr.io/getporter/examples/images/whalesay:latest"
        rm: true
        arguments:
          - cowsay
          - - ${ bundle.parameters.msg }

uninstall:
  - docker:
      run:
        image: "ghcr.io/getporter/examples/images/whalesay:latest"
        rm: true
        arguments:
          - cowsay
          - Goodbye World

After I test the bundle and verify that it’s ready for release, I use porter publish to push the new image ghcr.io/getporter/examples/whalesay:v0.2.0 to the registry.

Run that bundle

Now that the bundle is ready to use, the user running the bundle needs to give the bundle elevated permission with the Allow Docker Host Access setting. This is because giving a container access to the host’s Docker socket, or running a container with --privileged, has security implications for the underlying host, and should only be given to trusted containers, or in this case trusted bundles.

Let the whales speak!

$ porter install --reference ghcr.io/getporter/examples/whalesay:v0.2.0 --allow-docker-host-access
installing whalesay...
executing install action from whalesay (bundle instance: whalesay)
Install Hello World
 _____________
< Hello World >
 -------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/
execution completed successfully!

I can set the flag --allow-docker-host-access with the PORTER_ALLOW_DOCKER_HOST_ACCESS environment variable so that I don’t have to specify it for every command.

export PORTER_ALLOW_DOCKER_HOST_ACCESS=true

Now let’s see what else you can do with whalesay:

$ porter invoke whalesay --action=say --param 'msg=try it yourself!'
invoking custom action say on whalesay...
executing say action from whalesay (bundle instance: whalesay)
Say Something
 __________________
< try it yourself! >
 ------------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/
execution completed successfully!

This is hopefully just the first step towards first class support for Docker and Docker Compose within Porter bundles, especially now that Docker Compose has an open specification. If you are interested in collaborating with us to take this further, please reach out on the porter or docker mixin repositories!

Searching for Mixins and Plugins with Porter

Mon, 02 Mar 2020 00:00:00 +0000

Two of Porter’s great strengths lie in composability and extensibility. Mixins represent the building blocks for composing a bundle, offering functionality that can be utilized during the runtime of a bundle, and Plugins represent swappable backend storage solutions, enabling distributed, Day 2 bundle instance management. (Be sure to read Carolyn Van Slyck’s recent post around Plugins and Collaboration.)

The default installation of Porter includes a handful of useful mixins, including:

exec for running arbitrary shell commands
helm for managing Helm charts and releases
kubernetes for managing Kubernetes manifests and cluster operations

However, there are many more available for use with Porter. As the list grows and source code is distributed across many different GitHub orgs/users, we need a way to efficiently search for available mixins. In addition, a mechanism for mixin developers to add their own offerings to this searchable directory is necessary.

We created the Porter Packages repository to hold these directories, one for mixins and one for plugins. Adding an entry to the list is as simple as supplying a handful of details regarding the package in JSON form: the name of the package, a description of what it does, a URL where it can be installed from, etc.

The Porter CLI then references the appropriate list when a user searches, say, for a Terraform mixin:

$ porter mixin search Terraform
Name        Description                           Author           URL                                     URL Type
terraform   A mixin for using the terraform cli   Porter Authors   https://cdn.porter.sh/mixins/atom.xml   Atom Feed

We can then install this mixin via the provided URL, which in this case is of the Atom feed type:

$ porter mixin install terraform --feed-url https://cdn.porter.sh/mixins/atom.xml
installed terraform mixin v0.5.1-beta.1 (597a442)

The Terraform mixin is now available for use in our next Porter bundle. To peruse the full list of mixins, simply issue porter mixin search without any query.

Similarly, porter plugin search offers a way to discover plugins for Porter. Plugins offer storage solutions for bundle instance and credentials using the cloud of your choosing. We’re just getting started and hope that in the near future, parameter storage will also be included.

Thank you to the community for all of the fantastic package contributions thus far! We’re excited to see Porter’s ecosystem grow with each new mixin or plugin added to the list.

😎 Have a mixin or plugin not already included in either list? Please visit the Porter Packages GitHub repository and follow the instructions on how to add new entries to the lists.

🎉 Interested in developing a new mixin? Check out the Mixin Development Guide to get started. We hope to craft a similar guide for plugin development, but in the meantime, check out the code for the azure plugin via the Porter Azure Plugins repo.

Managing Bundles as a Team with Porter

Wed, 19 Feb 2020 00:00:00 +0000

One tenet of working on a great team, is that no one deploys alone. I may have originally deployed our application, but that doesn’t mean that I am responsible for patching it until the end of time, or until I run away screaming. I am excited to announce that Porter now fully supports teams managing a bundle collaboratively! 🙌

🔷 Sally deploys the application on Tuesday using secrets stored in the team’s Key Vault.

🔷 When a new version of the application comes out on Thursday, Adnan updates the deployed bundle.

🔷 Their manager Qi downloads Porter onto her laptop over the weekend and in minutes is running a custom bundle action to view logs to investigate a bug report.

These seamless handoffs are now possible because of two big efforts: Porter’s new plugin framework and changes to cnab-go supporting generic storage and credential resolution strategies.

Now your team can setup a cloud account, and share a Porter config file that says which plugin to use and how to connect to the account. Porter uses the plugin to resolve credentials against the team’s secret store, such as Azure Key Vault, and stores the bundle instance in cloud storage, like Azure Blob Storage.

This is a big step forward for collaborating on bundles. More importantly it is much more secure. Secrets plugins move the storage of credentials used by your bundles off of laptops and CI machines, back into secure secret stores where they can be managed by the team, encrypted at rest and not left around after the bundle is executed. Even if you are using Porter as a single user, you should move to using a secrets plugin.

With the latest release of Porter, the Azure plugin is installed by default so that people can try it out. Nothing about the plugin framework is specific to Azure, it is just the first plugin we implemented. We would love to see more plugins for other providers! Just like with mixins, anyone can write a plugin, distribute, and list it alongside the porter-authored plugins. Please reach out to us on the #porter Slack if you are interested in making a plugin.

😎 Already using Porter? Install the latest release, give the plugins tutorial a try and let us know what you think!

🎉 Ready to try Porter for the first time? Install, head over to the quickstart and then check out our learning page for a high level overview of CNAB, demos of bundles in action and more.

Porter – Blog

Porter 1.6.0: Porter Now Speaks MCP

Porter 1.6.0: Porter Now Speaks MCP

porter mcp: an AI assistant that actually knows your bundles

Also new in 1.6.0

Where dependencies are headed next

Feedback welcome

So, You Want to Share a Cloud Application?

What is a Cloud Native Application?

What is CNAB/Porter?

CNAB

Porter

Problems Facing Modern Cloud Solution

Embarrassment of Riches

Simplify and Speed Up Deployments

Why should I care?

Accelerating Solution Adoption

JoyOfNGINX

NGINX Unit on KinD (Kubernetes in Docker)

Porter Argo Demo

Security and Reliability

The Value of Porter

Call to Action

Porter Operator v1.0.0 is here!

What is the Porter Operator?

What’s new in v1?

Outputs

Delete all the things!

Checkout the Operator Demo

Recognizing our key contributors

Porter v1.0.0 is here!

What is Porter?

What’s new in v1?

Buildkit Support

Installations

Improved Data Persistence

Tighter Security

What’s next?

Porter's 2023 Roadmap

Porter Operator

Advanced Dependencies

Improved Bundle Security

Signing and SBOMs

Contributors Welcome!

Quickly set up a Porter environment with required plugins

Breaking change

Install multiple plugins with a single command

A more YAML friendly template delimiter

What does this change?

What do you need to change?

Upgrade your plugins to securely store sensitive data

Get those secrets out of your config

Ignoring Mixin Errors and Idempotent Actions

Ignore All Errors

Ignore Exit Codes

Ignore Output Containing a String

Ignore Output Matching a Regular Expression

Create Custom Idempotent Mixin Commands

Try it out

Helm3 Mixin Improvements

New Defaults

Upgrade or Install

Create Namespace

Atomic

New Settings

Removed Settings

1.0.0-alpha.3 is here!

Breaking Changes

MongoDB Support

Namespaces

Labels

Bundle State

Import credentials and parameter sets

Install the v1 Prerelease

Upgrade to the helm3 mixin

Porter v1 on the Horizon

Migrate from Docker App to Porter

View Logs From Previous Runs

Set Bundle Metadata on Build and Publish

Build Workflow

`porter mcp`: an AI assistant that actually knows your bundles