Plan Tiers

Documentation Index

Fetch the complete documentation index at: https://docs.cnap.tech/llms.txt

Use this file to discover all available pages before exploring further.

Your plan tier determines your resource limits, available instance types, and machine lifecycle rules. CNAP resolves your effective tier through a specific chain — understanding this helps you predict what happens when you upgrade, downgrade, or work across multiple workspaces.

​

Tier resolution

​

Workspace tier

Each workspace has its own plan:

• No active subscription → Free tier
• Pro plan active → Pro tier (set automatically when you subscribe)

The workspace tier controls quota limits, instance type filtering, and machine TTL.

​

User tier

Some operations need a user-level tier (rate limit naming, quota info display). Your user tier is the highest tier across all your workspaces:

• You belong to 3 workspaces: 2 Free + 1 Pro → your user tier is Pro
• You belong to 2 workspaces: both Free → your user tier is Free

This means upgrading one workspace to Pro also elevates your personal rate limits.

​

What each tier controls

​

Instance type filtering

When Karpenter asks “what instance types are available?”, the response depends on the workspace tier: This filtering happens at the API level — Karpenter never sees types outside the tier’s allowlist.

​

Quota enforcement

Quotas are enforced atomically in the database transaction when a machine record is created. This prevents race conditions — even concurrent requests can’t exceed the limit. Dual check model:

• Per-workspace: The workspace can’t exceed its plan’s allocation
• Per-user (free only): Prevents creating multiple free workspaces to circumvent limits

Pro workspaces skip the per-user check — you’re paying, so cross-workspace usage is fine.

​

Machine TTL

​

Auto-scaling behavior

​

When tiers change

​

Upgrade (Free → Pro)

Takes effect immediately:

1. GetInstanceTypes returns all types (not just the free-tier 3)
2. Quotas increase (1 → 3 machines, 2 → 8 CPU, etc.)
3. Machine TTL stops — existing machines no longer expire
4. Auto-scaling limits expand
5. Karpenter sees the new types within 30 seconds (Go provider cache TTL)

​

Downgrade (Pro → Free)

Takes effect at end of billing period:

1. CNAP-managed machines are suspended (not deleted)
2. Auto-scaling is paused on managed clusters
3. Quotas revert to free limits
4. Instance type filtering returns to the free-tier 3
5. BYOM machines are unaffected

​

BYOM (any tier)

Adding your own cloud API key bypasses all quota enforcement:

• No machine count limit
• No CPU/memory limit
• No TTL
• All instance types available
• No auto-scaling restrictions

The only thing CNAP charges for is the management subscription (Pro plan). The cloud compute costs go directly to your provider.

​

How enforcement works

Quota enforcement is atomic — concurrent requests cannot exceed the limit, even under race conditions. When a machine is created, the quota check runs in the same database transaction as the creation. If the limit would be exceeded, the creation is rejected and no resources are provisioned. This means you can’t accidentally exceed your plan limits by clicking “create” rapidly or running parallel API calls.

​

Instance type availability

When your cluster’s auto-scaler checks available instance types, CNAP filters the list based on your workspace tier:

• Free: Only small, affordable types are shown
• Pro: All provider types are available
• BYOM: All types in your cloud account

Plan changes take effect within seconds. After upgrading to Pro, new instance types become available immediately for your next scaling decision.