Plane Community Edition
You set up plane community edition by running its containers on your own Linux server. Then you create an admin account and invite your team into a shared workspace. Most teams deploy the app with default settings to start tracking issues fast. Still, default server setups often give engineers broad access to the host and database. Broad roles let anyone read private issue data or change system tables by mistake. How plane community edition architecture and roles work The app runs as a group
Security Control Plane: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up plane community edition by running its containers on your own Linux server. Then you create an admin account and invite your team into a shared workspace. Most teams deploy the app with default settings to start tracking issues fast. Still, default server setups often give engineers broad access to the host and database. Broad roles let anyone read private issue data or change system tables by mistake.
How plane community edition architecture and roles work
The app runs as a group of containers on a single host or cluster. A web frontend talks to a backend API service over an internal network. The backend service stores project records inside a relational database like PostgreSQL. It also uses a fast cache store to manage background jobs and user state. Object storage holds file attachments that users upload to their project issues.
Inside the app, access control happens at the workspace and project levels. Admins invite users and assign them specific roles like admin, member, or guest. Guests can only view or comment on the specific issues shared with them. Members can create issues, plan cycles, and organize modules across the workspace. Workspace admins manage billing settings, member lists, and high-level project rules.
This built-in role system works well for daily project management tasks in the browser. It keeps guests out of private projects and stops members from deleting workspaces. Still, the app role model only controls what happens inside the web interface. Your operations team still has to maintain the Linux host and database underneath.
Where native workspace permissions fall short
Running your own project tracker means your team owns the full data stack. Engineers must log in to the host server to run updates and check logs. They also connect to the database to run backups or fix broken migrations. Native app roles do not govern these direct server and database sessions at all.
Teams often share a single admin key for SSH or a master database password. Once an engineer logs in with that credential, they hold full control. The native setup decides who logs in, not what individual commands do in flight. A single bad query can drop project tables or expose private issue text. If customer emails or phone numbers sit in bug reports, queries return them raw.
Security Control Plane: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static credentials also make audit logs hard to read during a security review. Every database action shows up under the same shared admin user name. You cannot tell which team member ran a specific read or write statement. Revoking access when someone leaves the team requires rotating passwords across multiple services. Teams need a way to tie every command and query to a real person.
Managing host and database access for self-hosted trackers
To secure a self-hosted tracker, you must separate web roles from system access. Start by locking down the network so only trusted paths reach the database port. Remove shared SSH keys from the host and stop passing database passwords in chat. Tie every server and database login to your central identity provider instead.
Next, look at how engineers run maintenance commands against the live backend. Instead of granting full shell or database rights forever, scope permissions to specific tasks. Log every SQL statement and shell command with the exact user identity attached. Apply data masking to rewrite emails, phone numbers, and card numbers in query results. This keeps sensitive bug report details safe while engineers fix database issues.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between workspace roles and server access in Plane?
Workspace roles control what users can click and view inside the web app. Server access controls who can log in to the Linux host and database underneath.
Why do engineers need direct database access for a self-hosted tracker?
Engineers connect to the database to check slow queries, fix stuck migrations, and verify backups. They also use shell sessions to update containers and read system error logs.
How can teams protect sensitive data stored inside project issues?
Teams can use query masking to rewrite emails, phone numbers, and card numbers in results. This lets engineers fix database tables while keeping personal details hidden in the output.