Environments

Production

Service	URL	Host
Public site	https://www.soultales.com	Cloudflare Workers
Partner portal	https://ie.soultales.app	Cloudflare Workers
Partner docs	https://ie.soultales.app/docs	Built into dashboard
Platform docs	https://blueprints.soultales.app	Cloudflare Pages
CMS (Directus)	https://manage.soultales.app	Fly.io
Helpdesk (Chatwoot)	https://helpdesk.soultales.app	Fly.io

See Platform stack for scalability, costs, and security, Cost projection for estimated monthly spend, and Services & vendors for the complete list of external services used per package.

Staging (planned)

We run production only today. A dedicated app staging environment is on the platform roadmap so new features can be tested end-to-end before going live. Helpdesk (Chatwoot) does not need its own staging stack — the partner portal widget can keep pointing at production Chatwoot during staging tests.

Scope

Staging covers the main travel platform packages only:

Package	Staging target (planned)	Host
Public site	staging.soultales.com (or *.workers.dev preview)	Cloudflare Worker (soultales-www-staging)
Partner portal	staging.ie.soultales.app	Cloudflare Worker (soultales-partner-staging)
CMS (Directus)	manage-staging.soultales.app	Fly.io (real-ireland-app-staging, scale-to-zero)
Platform docs	—	Production or Pages preview deploys only
Helpdesk	—	Production (helpdesk.soultales.app)

Architecture

flowchart LR
  subgraph prod [Production]
    PW[www.soultales.com]
    PD[ie.soultales.app]
    PF[Fly Directus min=1]
    PN[(Neon main branch)]
  end

  subgraph staging [Staging]
    SW[staging.soultales.com]
    SD[staging.ie.soultales.app]
    SF[Fly Directus min=0]
    SN[(Neon staging branch)]
  end

  subgraph shared [Shared]
    H[helpdesk.soultales.app]
    T[Turso staging DB]
    R[R2 staging bucket]
  end

  PW --> PF --> PN
  PD --> PF
  SW --> SF --> SN
  SD --> SF
  SD -.->|widget only| H

Workers and Pages are already serverless — staging adds separate worker names and KV namespaces, not always-on VMs. The only meaningful extra hosting is a second Fly.io app for Directus, configured with min_machines_running = 0 so it suspends when nobody is testing (accepting a 3–6 minute cold start when the CMS wakes up).

Data isolation

Resource	Production	Staging approach
Neon Postgres (Directus)	real_ireland_app on main branch	Neon branch — copy-on-write, compute scales to zero when idle
Turso (traveler auth)	Production libSQL database	Separate staging database (free tier allows many databases)
R2 (CMS media)	soultales-directus	Separate bucket or prefix + staging PUBLIC_MEDIA_CDN_URL
Cloudflare KV	Two SESSION namespaces	Two new namespaces for staging Workers
Clerk / Stripe	Live keys	Test-mode instances and webhooks (no extra subscription cost)

DIRECTUS_OUTBOUND_SECRET must match between the staging dashboard Worker and staging Fly Directus — same rule as production. Partner setup scripts and Turso migrations should run against staging first (see Partner flows and Auth & users).

Deploy flow (planned)

1. Merge feature work to a staging branch (or open a PR that deploys to staging).
2. GitHub Actions use a staging environment with staging-specific secrets (Directus URL, Neon branch connection string, Clerk/Stripe test keys, OAuth redirect URIs).
3. Frontend and dashboard builds point at staging Directus so content is baked in at build time, matching production behaviour.
4. After QA on staging, promote to main → production deploy workflows (unchanged).

See Cost projection for estimated extra monthly spend (~€5–15/mo with scale-to-zero Directus).

Local development

Package	Default dev URL
frontend	http://localhost:4321
dashboard	http://localhost:4321 (use a different port if running both)
docs	http://localhost:4321
backend	http://localhost:8055 (Docker or pnpm start in backend)
helpdesk	http://localhost:3000 (Docker Compose)

Run one Astro app at a time, or pass --port to avoid conflicts.