# Official sources

Use this reference only when grounding Contabo instance specifications, region availability, addon capabilities, or API behavior for capacity planning.

## Contabo documentation

Use these as starting points, not as proof of current product availability or the user's live account state:

- https://api.contabo.com/ — Contabo OpenAPI reference (instance creation, product IDs, region codes, addon parameters)
- https://docs.contabo.com/ — Contabo user documentation (instance types, region coverage, Cloud-Init guides, Private Networking setup)
- https://github.com/contabo/cntb — cntb CLI tool (instance listing, secret management, Cloud-Init deployment)
- https://api.contabo.com/#tag/Instances — Instance operations API (product selection, region, userData, SSH secret IDs, addons)

## Grounding rule

Official Contabo documentation describes available instance tiers, region codes, addon capabilities, and API contract behavior at the time of publication. It does not prove current product availability in a specific region, live pricing, the user's active instances, or whether a particular addon can be added after creation. Prefer user-provided sanitized evidence or live read-only API responses for current-state claims. Label any instance specification or region availability claim sourced only from documentation as `documentation-based`. Confirm region-specific product availability via the API or Contabo support before committing to a multi-region plan.

# Safety checklist

Use this reference before producing a capacity plan that includes a contract period commitment, instance tier recommendation, Cloud-Init userData, or multi-region topology.

## Non-negotiables

- Never ask users to paste OAuth2 tokens, client secrets, API passwords, SSH private keys, or S3 secret keys into chat.
- SSH keys must always be referenced by Contabo secret IDs — never include raw private key material in API payloads, Cloud-Init fragments, or recommendations.
- Do not invent instance specifications, region availability, pricing, or contract terms. Label all specification claims as `documentation-based` since products and pricing may change.
- Require explicit acknowledgment of the contract period and its billing obligation before finalizing any deployment plan. Period selection is binding at instance creation and cannot be shortened.
- Review all Cloud-Init userData for embedded secrets, curl-pipe-sh patterns, hardcoded credentials, and commands that disable audit logging before including it in any plan output. Refuse to include userData that fails this review.
- Do not recommend a multi-region topology without confirming that required instance types and addons are available in all target regions.
- OAuth2 token values must never appear in plan output, scripts, or echo statements.

## Stress checks

- Does the selected contract period create an irreversible billing obligation that exceeds the user's stated budget or timeline? → Surface and require acknowledgment.
- Does the Cloud-Init userData contain raw credentials, unauthenticated package sources, or curl-pipe-sh execution? → Flag and refuse to include without remediation.
- Is the selected instance tier based on actual utilization data or inferred from a general workload description? → Label as inference if not confirmed.
- Does the plan require addons (Private Networking, Additional IPs) that may not be available or require separate provisioning steps in the target region? → Confirm availability before committing.
- What is the recovery path if Cloud-Init provisioning fails and the instance is in an unknown state?
- Is there a confirmed SSH access path that does not depend solely on Cloud-Init completing successfully?

## Evidence labels

Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Capacity plans built on inference alone must be clearly flagged as preliminary estimates requiring evidence confirmation before committing to a contract period.

# Workflow and output contract

Use this reference only when performing a full capacity planning review, deployment design, region evaluation, or instance tier comparison for a Contabo environment.

## Review domains

Check these areas before producing a capacity plan:

- Region selection: latency targets, compliance constraints, region availability, and redundancy requirements
- Instance tier fit: VPS (shared) vs. VDS (dedicated) vs. Storage VPS — CPU, RAM, storage, and network ceiling for the declared workload
- Contract period selection: 1/3/6/12-month obligations and their billing commitment at creation time
- Cloud-Init userData strategy: reproducibility, secret hygiene, and idempotency of the provisioning script
- SSH key strategy: Contabo secret IDs referenced in API payloads, never raw private key material
- Addon requirements: Private Networking (VLANs across instances), Additional IPs, Extra Storage, Custom Images
- Scaling topology: single-region vs. multi-region, horizontal scaling constraints, and network topology

## Safe workflow

1. **Frame scope**
   - Workload type and expected resource demand (CPU, RAM, storage IOPS, bandwidth):
   - Target region(s) and latency or compliance constraints:
   - Required contract period and budget envelope:
   - Cloud-Init or SSH key strategy requirements:
   - Explicit non-goals (e.g., no dedicated resources, no multi-region):

2. **Collect evidence**
   - Prefer user-provided workload data (utilization metrics, peak demand, team size, SLA targets).
   - Use read-only Contabo API calls for current instance inventory if live access is available.
   - Ground instance tier specs and region availability in official Contabo docs; label as `documentation-based` since specifications may change.
   - Label each claim as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.

3. **Stress-test the plan**
   - Does the selected instance tier have headroom for peak load or burst?
   - Is the declared contract period the lowest lock-in option that still meets the cost target?
   - Does the region have all required instance types and addons available?
   - Is the Cloud-Init userData free of embedded secrets or unauthenticated remote execution?
   - What is the recovery path if provisioning fails mid-flight?

4. **Recommend the smallest safe plan**
   - Prefer the lowest contract period that meets the budget, unless a longer period is justified by stability and cost savings.
   - Always declare the contract period and billing obligation explicitly in the plan output.
   - If the safest action is to start with a single VPS and scale, say that plainly.

## Output contract

Return this structure:

```markdown
# Contabo Capacity Plan: <scope>
## Executive summary
- Status: READY TO DEPLOY / READY WITH CAVEATS / NEEDS EVIDENCE
- Selected region(s):
- Selected instance tier(s):
- Contract period: <1 | 3 | 6 | 12> months — billing obligation acknowledged
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Instance plan
| Region | Instance tier | vCPUs | RAM | Storage | Contract | Monthly cost (est.) |
|---|---|---|---|---|---|---|
## Addon requirements
- <addon and justification or "none">
## Cloud-Init / SSH key strategy
- <strategy or "not required">
## Deployment sequence
1. <step> — validation: <check>
## Rollback or recovery path
- <path>
## Residual risk
- <risk or explicit none>
```