Portainer 2.17 is now available

Portainer version 2.17 includes a number of new features, fixes and updates. I've outlined the big ones below.

Top 10 Reasons to Upgrade to 2.17.1

1. Relative path support for Git stacks
2. Back up Portainer to S3-compatible providers eg. MinIO
3. Log viewer improvements
4. GitHub Container Registry (GHCR) support
5. Rolling restart for Kubernetes applications
6. Direct YAML editing in Portainer
7. Enforce code-based deployment on Kubernetes clusters
8. Edge devices moved to home page
9. Remote update of Edge Agents
10. Browse Edge devices that are deployed in async mode
    
    

• Back up Portainer to S3-compatible providers (BE)

Portainer Business Edition has long provided the ability to back up your Portainer config to an AWS S3 bucket. In 2.17 we've expanded this support, by popular demand, to S3-compatible providers such as MinIO. As long as your provider is S3-compatible, you should now be able to use them with Portainer.

• Log viewer improvements (BE)
  

• Relative path support for Git stacks (BE)

Often when deploying a stack you'll want to pre-populate your container's file system from your Git repository into pre-defined relative paths. 2.17 adds support for this with a toggle on your stack deployment, letting you spin up a stack and copy the necessary files into directories on your host automatically.

• Upgrade from CE to BE (CE)

Upgrading from the Community Edition of Portainer to the Business Edition has in the past needed you to jump into the command line and redeploy your Portainer installation, but now in 2.17 you can do this right from the Portainer UI. You can bring your own license key or sign up for a free trial, and Portainer will handle the upgrade for you automatically, getting you up and running on BE without any hassle.

• GitHub Container Registry (GHCR) support (BE)

We've now added the GitHub container registry to our list of supported registry providers in 2.17. This lets you connect to and browse your GitHub registry directly from within Portainer, as well as deploy containers from images stored there.

Kubernetes Management - new features in 2.17

• Rolling restart for Kubernetes applications (BE)

In the Kubernetes realm, we've added a rolling restart option to your deployments. Instead of terminating all your pods and restarting them from scratch when doing an update, you can now instead do a rolling restart of your application, reducing downtime. This is available via the Portainer UI as well as via an option on your application webhook, which means it can be used in your deployment automation.

• Improved Kubernetes defaults (BE/CE)

We've made some changes to the default cluster configuration in version 2.17 to more align with sensible standards. This includes automatically detecting new ingress controllers and the presence of the metrics API, as well as auto enabling storage options set as default in the cluster. These apply only clusters that you've newly added to Portainer - your existing clusters won't have their settings changed.

• Direct YAML editing in Portainer (BE)

Since the beginning, you've been able to view the YAML for your Kube deployments in Portainer, but in 2.17 you can now make changes to that YAML straight from the UI. Portainer uses the Kubernetes patch mechanism to apply these changes, so if you need to make a quick adjustment to a deployment you can jump straight into the YAML and get it done.

• Enforce code-based deployment (BE)

In 2.17 we've added the option, by popular demand, for cluster admins to enforce code-based deployment on their Kubernetes clusters, disabling the use of the form-based deployment approach. This restriction can be applied globally or on a per-cluster basis. This is to help provide admins with greater control over how applications are deployed and managed on their clusters.

• Enforce admin-only ingress creation (BE)

Along the same vein, 2.17 adds an option to restrict ingress creation to admins only. With this option on, non-admin users will still be able to use ingresses configured in the cluster, but won't be able to deploy new ones.

Edge Device Management - New features in 2.17

• Move Edge Devices to the home page (BE/CE)

In the Edge sphere, one of the big changes in 2.17 is moving of Edge Devices to the home page view alongside the traditional Portainer environments. This gives you a more unified view of your infrastructure than before, making it easier to use and manage your setup no matter what type it is.

• Browsing async environments (BE)

Now that Edge Devices are on the home page, we've also added the ability to browse Edge devices that are deployed in async mode as you would a traditional environment. You can browse your environment as you would any other in Portainer. This is based on the use of snapshots, so what you're seeing will depend on how recent your snapshot is.

• Remote update of Edge Agents (BE)

2.17 also introduces the ability to remotely update your Edge Agent deployments from within Portainer, removing the need to connect to each environment individually when a new version comes out. You can schedule an update across multiple devices at a time that suits you, and Portainer will handle the rest. There are some limitations with this feature at the moment and it is considered a beta, so bear that in mind when trying it out.

• Pre-pull images on Edge devices (BE)

When deploying an Edge stack across a number of devices, you may want to pre-pull your images to the device to make sure they get there before you deploy. In 2.17 we've added the option to pre-pull images on Edge stack deployments, and when enabled Portainer will pull all the needed images to the remote environment and ensure they have been pulled successfully before starting the stack, and will let you know if it wasn't able to do so. This should improve the reliability and stability of your Edge stack deployments.

These are the major new features and changes in 2.17. For a full list of changes, please refer to our release notes.

Need more than 3 nodes?
Talk to our friendly sales team to ask about pricing for your use case.

Ready to Upgrade?
Follow the instructions in our documentation to upgrade Portainer.