Three changes shipped together, and they answer the same question: who is allowed to see and use what, inside a workspace that has grown past a handful of people.
Projects can be closed
On Organization and Enterprise plans, a project can be restricted to a chosen list of members and roles.
A project someone cannot reach is not shown to them at all - not its applications, not its services, not its buckets. It is not listed and then refused, which tells people a project exists and that they are not in it. The workspace owner and the built-in Admin role always keep access, so a restriction cannot lock the workspace out of its own project.
This is the piece that makes a shared workspace usable for agency work: one client per project, and the people on that client's work are the only ones who see it.
Resources can be assigned to projects
A compute resource can now be dedicated to specific projects, under Project - Settings - Resources. Only the projects it is assigned to may deploy on it.
Two things are worth being precise about, because the direction is easy to get backwards:
- Assigning restricts the resource, never the project. A project with assigned resources can still deploy to the shared pool. The assignment says who may use the box, not where the project must run.
- If the resource still runs workloads from another project, the refusal names them and offers to assign the resource to those projects too, instead of failing with nothing to act on.
Removing an assignment returns the resource to the shared pool and moves nothing that is already running.
Everything can change project
Applications, static sites, services, stacks and buckets can all move between projects from their own settings. A stack takes every application and service it runs with it. The workload keeps running on the same resource throughout - a project is an organisational boundary, not a placement.
Buckets became project-owned in the same release: a bucket can sit in a project like everything else, or stay at workspace level.
API tokens that belong to the workspace
Workspace API tokens are separate from personal ones. A workspace token has its own permission list and its own project scope, and:
- It keeps working when the person who created it changes role.
- It stops working when that person loses access to the workspace.
- Editing one takes effect immediately, and lands on the activity feed with an author.
The practical difference is CI. A pipeline authenticated with somebody's personal token breaks the day that person's role changes, and quietly keeps working the day they leave. A workspace token does neither.
API tokens and webhooks now live in their own Developers tab in workspace settings, leaving Integrations for connections to other products.
How to use it
Restrictions and assignments are dashboard features today, under the project's own settings. Workspace tokens are created in Settings - Developers, and behave like any other bearer token against the API:
curl https://app.miget.com/api/v1/apps \
-H "Authorization: Bearer $MIGET_WORKSPACE_TOKEN"
A token's permissions are the intersection of what you granted it and what its owner may do, so a token can never be used to exceed the access of the person it belongs to.