Tech Expert & Vibe Coder

With 14+ years of experience, I specialize in self-hosting, AI automation, and Vibe Coding – building applications using AI-powered tools like Google Antigravity, Dyad, and Cline. From homelabs to enterprise solutions.

Setting Up Portainer with RBAC to Give Family Members Safe Access to Specific Containers Only

Why I Set Up Portainer RBAC for My Family

I run a Proxmox home server with dozens of Docker containers. Some handle critical infrastructure (DNS, monitoring, backups). Others are for media, automation, or experimental projects. My family wanted access to a few specific containers—mostly media-related tools and a couple of utility apps—but I didn't want them accidentally stopping my DNS server or deleting a production database.

The problem wasn't trust. It was safety. Docker's default permissions are all-or-nothing. If someone has access to the Docker socket, they can do anything. I needed a way to give limited, safe access to specific containers without creating separate VMs or overly complex networking rules.

That's where Portainer's Role-Based Access Control (RBAC) came in. I'd been using Portainer Community Edition for years to manage containers through a web UI, but the free version doesn't include granular user permissions. I decided to try Portainer Business Edition specifically for RBAC, knowing I could test it with their trial before committing.

My Setup and What I Actually Used

I run Portainer as a Docker container on my main Proxmox VM. The environment includes:

  • A single Docker host (not Swarm, not Kubernetes)
  • Around 40 containers, including Plex, Syncthing, Home Assistant, and several n8n workflows
  • Three family members who needed access to 4-5 specific containers each

I installed Portainer Business Edition by replacing my existing Community Edition container. The process was straightforward—same volume mounts, same port mappings. After restarting, I activated the Business trial through their licensing portal.

Creating Users and Assigning Roles

Portainer Business includes several built-in roles. I focused on two:

  • Operator: Can start, stop, restart, and view logs for containers. Cannot create or delete anything.
  • Helpdesk: Read-only access. Can view container status and logs but cannot make any changes.

I created individual user accounts for each family member under User-related > Users. Portainer uses local authentication by default, which worked fine for my use case. I set simple passwords and required them to change on first login.

Restricting Access to Specific Containers

This is where RBAC gets specific. Portainer doesn't let you assign roles to individual containers directly. Instead, it uses a combination of:

  • Environment-level roles: What a user can do across the entire Docker host
  • Resource ownership and teams: Which containers a user can see and interact with

Here's what I did:

  1. I assigned each family member the Operator role at the environment level (my Docker host).
  2. I created a Team called "Family Media" and added the relevant users.
  3. I went to each container I wanted them to access (Plex, Syncthing, etc.) and changed the Access control setting to Restricted.
  4. Under the restricted access settings, I added the "Family Media" team with the Operator role.

This meant they could only see and interact with containers explicitly shared with their team. Everything else was invisible to them in the Portainer UI.

What Worked (and Why)

The setup worked as intended. Family members could log in, see only their assigned containers, and perform basic operations—start, stop, restart, check logs. They couldn't:

  • See or touch any other containers
  • Delete containers or volumes
  • Access the Docker host itself
  • Change Portainer settings

The Operator role was the right balance. It gave them enough control to troubleshoot (like restarting Plex if it froze) without the ability to cause real damage.

I also appreciated the Effective Access Viewer under User-related > Roles. It showed exactly what each user could access across all environments. This made it easy to verify permissions without logging in as each user.

Why This Approach Made Sense

Using Portainer RBAC avoided several alternatives I considered:

  • Separate VMs per user: Too much overhead for a few containers.
  • SSH access with Docker commands: Still gives too much control, harder to audit.
  • Custom scripts or proxy layers: More work to build and maintain.

Portainer's RBAC is built into the tool I was already using. It required no additional infrastructure.

What Didn't Work

Community Edition Doesn't Have RBAC

This was the biggest limitation. Portainer CE allows multiple users, but everyone gets full admin access. There's no way to restrict permissions. If you need RBAC, you must use Business Edition, which is a paid product after the trial.

I tested the trial for 30 days. After that, I had to decide whether the cost was worth it for a home lab. For my use case, it was—but I can see how this would be a dealbreaker for some.

Container-Level Permissions Are Indirect

You can't directly assign a user to a single container. You have to use teams and resource ownership, which adds a layer of indirection. For a small number of users and containers, this was manageable. If I had dozens of users with overlapping but slightly different permissions, it would get messy quickly.

No Native Support for External Auth in My Setup

Portainer Business supports LDAP and OAuth for authentication, but I didn't set that up. I'm using local Portainer accounts, which means managing passwords separately. If I ever expand this to more users, integrating with my existing authentication system (like Authelia or Authentik) would make more sense.

Logs and Console Access Are Still Powerful

Even with the Operator role, users can view container logs and open a console into a running container. For most of my containers, this is fine. But if a container had sensitive environment variables or config files, someone with Operator access could potentially see them through the console.

I mitigated this by only granting access to containers where this wasn't a concern. Anything with secrets stayed fully restricted.

Key Takeaways

  • Portainer Business RBAC works well for giving family members safe, limited access to specific Docker containers.
  • The built-in Operator role is a good fit for non-admin users who need to manage containers but shouldn't create or delete anything.
  • RBAC is only available in Portainer Business Edition. The free Community Edition doesn't support granular permissions.
  • Setting up access involves teams and resource ownership, not direct user-to-container assignments. This works but requires some planning.
  • Even restricted users can view logs and open consoles, so don't grant access to containers with sensitive data unless you trust the user completely.
  • For a small home lab with a few users, the trial period is enough to validate the setup. For long-term use, you'll need to pay for Business Edition or find another solution.

If you're running Docker at home and need to share access without giving everyone full control, Portainer's RBAC is one of the cleanest ways to do it. Just know it's not free, and it's not infinitely flexible—but for my use case, it solved the problem without adding complexity.