Portainer is packed with features
- Audit logging
- Automatic stack updates
- Change window
- Container status indicator
- External authentication
- Force redeploy
- Hide anonymous Docker Hub
- Hide internal authentication prompt
- New image availability
- Notification log
- Registry management
- S3 backup
- Store git credentials
- User auto sync
- Webhooks for Docker
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.
Automatic stack updates
Take advantage of your existing automation and CI systems and trigger a redeploy of your container, stack or service through a webhook.
Change window configuration
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.
Container status indicator
Easily see which containers and services are running or stopped, healthy or unhealthy, from the list view and within the container or service details.
Easily configure your external authentication provider
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.
Hide anonymous Docker Hub
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.
Hide internal authentication prompt
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.
Portainer can be configured to accept Lightweight Directory Access Protocol (LDAP) authentication if your organization has implemented LDAP or Active Directory authentication. When users attempt to log into Portainer, the application will authenticate them against your LDAP directory or Active Directory. If authentication is successful, the user is allowed to log into Portainer.
New image availability
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.
Role-based access control (RBAC)
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.
Registry browser / management
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 as well as custom Docker registries, all your images are available right in Portainer.
Back up Portainer to S3
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 a S3 bucket. You can schedule automated backups to your S3 bucket directly within Portainer.
Store git credentials
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.
Automatically sync users from your external auth provider
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.
Webhooks for Docker
- Create KaaS clusters
- Import via kubeconfig
- Load balancer quotas
- Namespace access
- Pod security constraints
- Resource overcommitment
- Resource quota
- Storage quotas
Create Kubernetes-as-a-Service clusters with cloud providers
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.
Import your existing cluster with kubeconfig
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.
Load balancer quota management
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.
Namespace access restrictions
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.
Pod security constraints
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.
Storage quota management
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.
- ARM32 support
- Async mode
- Bulk device onboarding
- Manage async edge devices
- Nomad orchestrator support
- Pass-through host env variables
- Private registries at the edge
- Waiting room for edge devices
In order to run across a wide range of low-power devices, the Portainer Edge Agent supports running on the ARM32 architecture, as well as ARM64 and x86_64, giving you a vast range of compatible devices for your Edge deployments.
Edge Agent async mode
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.
Bulk device onboarding
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.
Manage async edge devices
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.
mTLS for Edge Agent communications
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.
Nomad orchestrator support
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.
Pass through host environment variables
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.
Private registries at the edge
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.
Waiting room for edge devices
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.