With Miget you buy capacity, not per-service billing. You pick one plan - a fixed amount of CPU, RAM, and storage - and deploy as many apps, services, workers, and cron jobs as you want inside it. Your price does not change when you add another service.
A plan is a pool of compute. Adding a fifth app, a background worker, or a scheduled job draws from the same pool you already paid for - it does not add a line item.

​
What a Resource includes

A Resource is a Kubernetes namespace running on a Kubernetes cluster in a specified region. It includes Miget’s Fair Scheduler and a resource quota, allowing workloads to run efficiently within the allocated resources and ensuring fair usage across tasks. Every Resource gives you three things:
  • A namespace - an isolated space on a regional Kubernetes cluster where all your workloads live.
  • A resource quota - the fixed CPU, RAM, and storage ceiling defined by your plan.
  • The Fair Scheduler - the mechanism that distributes CPU across your services so no single workload starves the rest.
Because everything runs inside one namespace with a shared quota, you can right-size a single plan to your whole project instead of provisioning and paying for each service separately.

​
Shared vs dedicated CPU

The shared-vs-dedicated distinction is about how your plan’s CPU maps to the underlying hardware - specifically, whether the physical cores are shared with other customers or reserved for you alone.
  • Hobby plans use shared CPU. Your CPU capacity is drawn from cores that are shared with other Hobby customers on the same host. The Fair Scheduler still splits that capacity fairly across your own apps, but because the underlying cores are shared across tenants, raw performance is best-effort and not guaranteed. This is a great fit for development, side projects, and bursty workloads.
  • Pro plans use dedicated CPU. You get full CPU core(s) reserved exclusively for you - never shared with other customers - for consistent, predictable production performance. You choose how to use them: pin entire cores to specific apps, or let the Fair Scheduler distribute your dedicated cores across your apps.
On both tiers, the Fair Scheduler manages how CPU is shared across your own apps. The plan tier only determines whether the underlying cores are shared with other customers (Hobby) or reserved for you (Pro). RAM and storage are always governed by your plan’s quota.

​
Assigning a resource to projects

A resource is shared by the whole workspace by default: a workload from any project can be placed on it. Assigning a resource to one or more projects turns that into an allow-list — once assigned, only those projects may place workloads on it. Assign a resource under Project → Settings → Resources. It needs both projects:manage and resources:manage, because assigning narrows a resource the whole workspace could otherwise use.

​
It restricts the resource, not the project

A project with assigned resources may still deploy onto any unassigned one. The rule runs in one direction only, which is what makes it safe to adopt gradually: assign the resource you want isolated, and everything else carries on as before.

​
Assigning declares what is already there

A workload cannot be moved between resources — it is placed once, when it is created. So a resource can only be assigned to the projects whose workloads are already on it, plus any others you add deliberately. If the resource still runs workloads from a project outside the list, the assignment is refused and the message names those projects. Three ways forward, cheapest first:
  1. Add that project to the assignment as well. The resource then serves both, and nothing moves.
  2. Move the foreign workloads into this project. They keep running on the same resource; only ownership changes.
  3. Delete and recreate them — only necessary when a workload must not change project.
Removing an assignment is always safe and needs no cleanup: the resource returns to the shared pool and every workload already on it stays exactly where it is, because an unassigned resource accepts every project.

​
Moving a workload between projects

Applications, static sites, services, stacks and buckets can all be moved to another project from their own settings; a stack takes every application and service it runs with it. The workload keeps running on the same resource throughout. That is also the one way this can bite: if the resource is assigned to projects that do not include the destination, the move is refused. Assign the resource to the destination project as well, or move the workload somewhere its resource is allowed to serve.

​
Add-ons

If your workloads outgrow your plan, you can extend it with modular add-ons for more CPU, more RAM, or more storage. Add capacity to the dimension you actually need without jumping to an entirely different plan. See Plans for the current tiers and add-on options.

​
Free tier

A free tier is available for small workloads, so you can try Miget and run lightweight projects at no cost. See Free tier for what it includes.

​
Next steps

How the Fair Scheduler works

Understand how CPU is distributed fairly across your apps in real time.

Compare plans

See the full plan tiers, quotas, and add-on options to pick your capacity.