Portainer is packed with features

Portainer provides a log of all user authentication requests, and journals the success or failure of each login as a record of when users engaged with Portainer. This log is retained for one week before being purged.

Take advantage of your existing automation and CI systems and trigger a redeploy of your container, stack or service through a webhook.

Don’t want your automatic updates to take place during work hours? With the change window feature you can set up a timeframe in which application updates are allowed to happen, and outside of this time frame automatic updates will not occur.

Easily see which containers and services are running or stopped, healthy or unhealthy, from the list view and within the container or service details.

If you’re using an external authentication provider such as Azure Active Directory, Google or Github, Portainer comes with preconfigured defaults to help you set this up quickly and without fuss. If you find you need to adjust these defaults for your particular needs, you can do that too.

When your application is deployed from a Git repository, you can enable this feature to automatically keep it in sync with whatever is in the repo. This way, Git becomes your “source of truth”, so you can ensure you’re running the correct version of your application on your environments.

By default the Docker Hub (anonymous) registry is available to all users. If you would prefer to hide this from the registry selection, you can do so with Portainer.

With external authentication configured, you can opt to hide the option to log in with Portainer’s internal authentication, enforcing that logins can only be processed by your authentication provider.

See at a glance whether your container images are up to date with what’s in the remote repository. Green means up to date, and red means there’s a newer version of the image available in the upstream repository.

Missed one of the pop up notifications, or need to look back on the history? In Portainer Business Edition we have a log of all the notifications your user has received, so you can easily check what you might have missed.

If you’re using Portainer inside an organization with established authentication systems in place you will likely want to exploit them rather than create something new. Portainer allows you to easily integrate Microsoft, Google and Github based OAuth systems, letting you onboard and manage team members without needing a separate access control system.

In Portainer Business Edition, we provide pre-configured templates for Microsoft, Google and Github's OAuth systems, as well as the option to configure a custom OAuth setup.

With Portainer’s role-based access control (RBAC), you can configure fine-grained access controls for your environments, whether they’re Docker, Swarm or Kubernetes. There are multiple roles available to choose from, each with their own pre-defined set of privileges, targeted at a range of different user types. Users can be directly (or as part of teams) assigned roles and can be given levels of access on a per-environment basis.

Using Portainer you can easily manage your image registries from one interface. With compatible registry types you can not only browse registries and their associated image repositories, but you can also manage and manipulate associated tags. With registry support for private Docker Hub accounts, AWS ECR, Quay,io, ProGet, Azure, Gitlab, and GitHub as well as custom Docker registries, all your images are available right in Portainer.

Ensuring your Portainer installation is backed up is crucially important in a production environment, and Portainer provide the ability to back up and restore your instance both as a local file and via S3 to AWS or S3-compatible providers such as MinIO. You can schedule automated backups to your S3 bucket directly within Portainer.

When you're using git repositories to deploy your applications, you might find you're needing to reuse the same credentials for multiple deployments. In Portainer Business Edition, you can save your credentials for use in your deployments. Credentials are saved to your user account in Portainer, and are only usable by you.

When using a Microsoft Active Directory authentication provider, Portainer supports the auto-population of users within Portainer from Active Directory, based on the configuration you set.

If you need to spin up a new Kubernetes cluster at a cloud provider, you can do so on-demand and to your specifications directly within Portainer. With support for cloud providers such as Civo, Linode, Digital Ocean, Google Cloud, AWS and Azure, a new Kubernetes cluster with the Portainer Agent automatically deployed is a few clicks away.

With Portainer Business Edition, you can install and configure a MicroK8s Kubernetes cluster directly onto fresh servers - VMs or baremetal - from within the Portainer UI. All you need is SSH access to the servers and you're good to go.

If you have an existing Kubernetes cluster you’d like to manage with Portainer, a kubeconfig file may be all you need. You can import the kubeconfig file and Portainer will then connect and deploy the Portainer Agent into your cluster, allowing you to connect and administer the cluster straight away.

Portainer lets an administrator set per-namespace limits on load balancer quotas. This way, you can better manage the costs associated with your load balancer resources in your Kubernetes clusters.

With Portainer, you can restrict access to the default namespace, forcing users to deploy applications on a separate namespace. This ensures that applications are allocated the resources they need without conflicting demands, as well as providing the security of separate namespaces.

When you're sharing an environment between teams, you might want to restrict the access each pod has to limit risks. Portainer Business Edition lets you manage and apply pod security policies directly, on a per-environment basis.

Portainer allows an administrator to disable resource overcommitment on the Kubernetes cluster, as well as determine the percentage of resources to allocate to running Kubernetes within the cluster. This helps you maintain the health of your cluster, and ensure the system won’t be compromised by resource-hungry applications or misconfigurations.

Set a quota assignment per namespace to enforce resource limits. 

Sometimes you may need to redeploy your application without taking it offline to cause minimal disruption to your users. With Portainer Business Edition you can choose to perform a rolling restart rather than a redeploy to help in this regard. This can be done both via the UI and through application webhooks.

Need to limit the amount of storage a specific  namespace can use? With Portainer, you can set quotas at the namespace level, determining the amount of storage an application is allowed to consume within a given cluster.

Portainer Edge Agents can be configured to function in async mode, disabling the tunnel between the agent and the Portainer Server and letting you define the communication intervals between the Edge Agents and the Portainer server. This lets you customize your communications to suit your requirements and restrictions.

When you have a large number of Edge Devices to provision, setting up each device individually isn’t feasible. With Portainer, a deployment script can be pre-generated ready for connection to Portainer on deployment. And with support for FDO and OpenAMT, your devices can even boot from scratch and be automatically provisioned and added to your Portainer instance.

Async mode means that you're not directly interfacing with your devices, so how do you manage them? With Portainer, you can browse snapshots of your individual Edge devices to ensure they're working as expected, as well as run commands like start, stop, restart and delete on your deployments directly.

With mutual TLS (mTLS), you can add an additional layer of security to the Edge Agent communications by encrypting the traffic with certificates from your own certification authority (CA). Under this setup, if a third-party system attempts to communicate with the Portainer Server and is not using a certificate signed by the certificate authority it will be rejected.

Through the Edge Agent, Portainer provides support for the Nomad orchestrator, allowing you to deploy and manage jobs on your Nomad nodes and clusters through the familiar Portainer interface.

Often across a fleet of Edge devices you may need to customize the configuration based on the specific device (for example, a physical location tag). The Portainer Edge Agent allows you to pass environment variables from the host through to the Edge Agent’s container environment, letting you take advantage of host options within your stacks.

When deploying an Edge stack across a number of devices, you want to ensure the needed images make it there successfully. With Portainer Business Edition, you can specify in your Edge stack to pre-pull needed images on deployments, which tells each device that it needs to successfully pull the images before proceeding with the deploy, reducing the amount of deployment issues you might run into.

You’re not just restricted to public container images on your Edge Agents. Using Portainer you can deploy your workloads to your Edge devices from private registries in the same way you would any public image.

The Edge Devices Waiting Room functionality lets you pre-load Edge devices with a script to deploy the Edge Agent and connect back to the Portainer Server without having to pre-configure the environments. Newly connecting devices go into a "waiting room", where an admin user would approve or deny those devices connecting to the environment. This is extremely powerful if you're deploying a large number of devices and aren't able to manually configure each one when they're connected for the first time.