Workspaces, Members & Roles

​

Workspaces

A workspace is the top-level organizational unit in Miget. Every user has at least one workspace, and all resources (apps, services, projects, databases) belong to a workspace.

​

Workspace Types

Miget offers different workspace plans to match your team’s needs:

​

Creating a Workspace

When you sign up, a default workspace is created for you. You can create additional workspaces from your dashboard to organize different projects or teams.

---

​

Members

Members are users who have access to a workspace. Anyone holding the workspace:members permission — the Admin role by default, and always the workspace owner — can invite new members and manage their access.

​

Member Statuses

​

Inviting Members

1. Navigate to Settings → Members in your workspace
2. Click Invite Member
3. Enter the email address and select a role
4. The invitee receives an email with instructions to join

Once invited, the member will appear in the Pending Invitations list until they accept. An invitation is valid for 24 hours; after that it shows as expired and has to be resent from the same list.

​

Managing Members

Anyone with the workspace:members permission can:

• Change roles - Update a member’s role to adjust their permissions
• Suspend members - Temporarily revoke access without removing them
• Reactivate members - Restore access to suspended members
• Remove members - Permanently revoke access

​

Transferring Ownership

Only the current owner can hand a workspace over, from Settings → Members using the crown action next to an active member. The new owner must already be an active member, and must not own another workspace with the same name. When the transfer completes, both of you are notified by email and the previous owner stays in the workspace as a member with the Admin role.

---

​

Roles

Roles define what actions members can perform within a workspace. Miget provides built-in roles and supports custom roles for Organization and Enterprise plans.

​

Built-in Roles

​

Permissions

Permissions are organized by domain:

​

Custom Roles

Custom roles allow you to create fine-grained access control tailored to your team’s needs. To create a custom role:

1. Navigate to Settings → Roles
2. Click Add Role
3. Enter a name and select the permissions
4. Click Create Role

On Organization and Enterprise plans the built-in roles can be edited too, so the comparison below describes their defaults rather than a guarantee. You can then assign the custom role to any workspace member.

​

Role Comparison

---

​

Why a role does not see something

A missing button is a permission, not a fault. A page does not show a control the role cannot use, so somebody without the permission for an action sees a page without it rather than an error after clicking. If a member reports that something “disappeared”, the answer is almost always in this section. The one deliberate exception is the paid VPN surface. A gateway and a site-to-site tunnel stay visible and greyed for anyone who can operate a network, with a line saying who to ask, because that block is lifted by buying rather than by a role change.

​

Where the line falls

Operate runs what already exists. Manage owns three things beyond that:

• The life of a top-level record. Creating and deleting an application, a service, a bucket, a project, a resource or a private network.
• Anything that costs money. A VPN gateway and a site-to-site tunnel, which are billed monthly and hold a public address of their own.
• Anything that ends stored data. Deleting a database or resetting it.

Everything else — add-ons, cron jobs, ports and their public access, variables, secret files, settings, backups, replicas, password rotation — is operate, and a Collaborator has it.

​

Common questions

​

The same answer through the API

Every permission above applies identically to the API. A call a role cannot make in the panel answers 403, and a workspace API token is limited by its own permission list rather than by its creator’s role — a token created for read-only use cannot deploy, stop or scale an application, whoever made it.

---

​

Project Access

By default every project is open to the whole workspace: anyone who can see projects can see all of them. Organization and Enterprise workspaces can change that under Settings → General → Default project access; with it off, a new project is visible only to whoever created it until they share it. Project access closes a single project to a named list of people and roles, so a workspace can hold work that not everyone is meant to see.

​

Closing a project

1. Open the project and go to Settings → Access
2. Click Grant access and pick members from the workspace list, or a role — everyone holding that role reaches the project
3. The first entry you add is what closes the project

Removing the last entry reopens it to the whole workspace.

​

Who still gets in

An entry never locks out the people who have to be able to administer the workspace:

• The workspace owner always reaches every project.
• Holders of the built-in Admin role always reach every project.

A custom role never bypasses a restriction, whatever permissions it carries — including permission to manage members. If a custom role should reach a restricted project, add it to that project’s access list.

​

What a restricted project looks like to everyone else

A project someone cannot reach is not shown to them as forbidden — it is not shown at all.

• It is absent from their project list, and so are its applications, static sites, services, stacks and buckets in the lists those appear in.
• Opening one of them by URL gives a not found page rather than a permission error.
• Its resources drop out of resource lists and pickers if no other project they can reach is using them.

That is deliberate: an error saying “you may not see this project” would confirm the project exists, which is exactly what a restriction is meant to avoid.