Help:User journeys

User journeys are step-by-step worked examples for setting up Canasta on specific hosting platforms or solving specific operational scenarios. They sit alongside the reference pages (see Help:About the user guide for the three-tier model): reference pages describe what a feature is and how it conceptually works in platform-neutral terms, while a user journey shows one operator's actual flow end-to-end — from provisioning, through configuration, to a working wiki.

Each journey is a worked example, not the only way. For the canonical conceptual material, follow the cross-links into the reference pages.

When to read a journey

• You're considering Canasta on a specific platform combination and want to see what it actually looks like before committing.
• You're an experienced operator setting up that combination for the first time and want a starting point you can adapt.
• You want to compare approaches across platforms.

When to write one

If you've stood up Canasta in a way other operators might want to replicate (a managed-cloud combination, a self-hosted setup with specific tooling, an unusual operational scenario), please contribute a journey. See Help:Contributing for how.

Available journeys

(Pages are added as journeys are written. This index will grow over time, including with operator contributions.)

AWS

• Help:User journeys/Canasta on AWS EKS with RDS — fully managed AWS deployment using EKS for Kubernetes and RDS for the MariaDB database.
• Help:User journeys/Canasta multi-node on AWS EC2 with k3s — self-managed Kubernetes (k3s) on commodity EC2 instances with NFS-backed shared storage and a multi-replica web tier.

Azure

(None yet. Contribute one if you've done this.)

GCP

(None yet.)

Self-hosted / other

(None yet.)

Operational scenarios

(None yet — examples to come include backup-to-S3, image storage on object stores, multi-environment promotion via GitOps.)

Journey conventions

To keep journeys consistent and contributable, each journey follows a fixed shape:

1. Header block: platform, time budget, cost estimate at idle.
2. One-paragraph intro: what the journey accomplishes, who it's for, and a pointer to the reference page it complements.
3. Prerequisites: tools (with versions where it matters), account types, costs, prior knowledge.
4. Numbered phases: typically Provisioning → Configuration → Validation. Each step is a copy-pasteable command (with placeholders) plus an explanation of why if non-obvious.
5. Cleanup / teardown: always present. Order-dependent steps spelled out so operators don't get billing surprises.
6. Production considerations: what the journey simplified that real production should add (multi-AZ, IAM-tightened roles, ACME prod certs, etc.).
7. Troubleshooting: common pitfalls specific to this journey, not the general Help:Troubleshooting catalog.

Cloud consoles and managed-service APIs change over time. Treat each journey as a starting point rather than a verbatim recipe — confirm specific details (instance types, console UI, IAM policy names) against current vendor documentation before running production traffic.