Skip to main content

External Services Overview

Last reviewed: 2026-05-13
Maintained by: Engineering

This page lists the external platforms and hosted services currently referenced by the repo or current docs. It focuses on purpose, ownership, config touchpoints, and safe environment notes.

Status legend:

  • Implemented: referenced by repo code and/or current docs as part of the working setup
  • Partial: used in some flows, but not fully documented across every surface
  • Template-ready: included as a placeholder because the team needs the slot, but the repo does not yet document a stronger standard

Render​

Status:

  • Implemented

Purpose:

  • current documented API hosting target

Used by:

  • apps/api

Relevant env vars:

  • environment-managed API runtime values
  • any Render-specific secrets or service settings should stay out of committed docs

Where configured:

  • hosted Render service settings
  • team-managed deployment/infrastructure configuration

Local / staging / prod notes:

  • not used for normal local development
  • staging and production API hosting in this portal now points to Render

Railway​

Status:

  • Partial

Purpose:

  • historical or optional API hosting reference in older repo documentation and workflow naming

Used by:

  • not currently treated as the active API hosting standard in this docs portal

Relevant env vars:

  • RAILWAY_TOKEN
  • RAILWAY_PROJECT_ID
  • RAILWAY_ENVIRONMENT_ID
  • RAILWAY_SERVICE_ID_API

Where configured:

  • legacy or still-unmigrated workflow/config wiring where present

Local / staging / prod notes:

  • do not treat Railway as the current API hosting standard when reading this portal
  • if Railway appears elsewhere, treat it as historical or optional rather than currently used

Vercel​

Status:

  • Implemented

Purpose:

  • current documented host for web apps

Used by:

  • apps/manager-desk
  • apps/back-office in hosting docs

Relevant env vars:

  • VERCEL_TOKEN
  • VERCEL_ORG_ID
  • VERCEL_PROJECT_ID_MANAGER_DESK
  • app-local NEXT_PUBLIC_* runtime vars

Where configured:

  • GitHub Environment secrets
  • Vercel project settings
  • .github/workflows/deploy.yml

Local / staging / prod notes:

  • local development does not require Vercel
  • Manager Desk deploy automation is documented
  • Back Office Vercel hosting is documented, but a dedicated deploy step is not currently shown in repo automation

Expo / EAS​

Status:

  • Implemented

Purpose:

  • hosted mobile builds and Expo project integration

Used by:

  • apps/zgrid-mobile

Relevant env vars:

  • EXPO_PUBLIC_API_URL
  • EXPO_PUBLIC_APP_ENV
  • EXPO_PUBLIC_EAS_PROJECT_ID
  • EXPO_PUBLIC_SENTRY_*

Where configured:

  • apps/zgrid-mobile/.env for local work
  • Expo / EAS environment settings for hosted builds

Local / staging / prod notes:

  • local work uses Expo CLI and local API URLs
  • hosted builds should use environment-managed values only

Cloudflare DNS​

Status:

  • Template-ready

Purpose:

  • placeholder slot for domain and DNS ownership documentation

Used by:

  • hosted web/API entrypoints once standardized

Relevant env vars:

  • none currently documented in the repo

Where configured:

  • external dashboard, not currently documented in repo detail

Local / staging / prod notes:

  • keep this as a documentation placeholder until the team decides to record concrete DNS ownership/process details here

Cloudflare R2​

Status:

  • Implemented

Purpose:

  • object storage for issue attachments and related signed upload/read flows

Used by:

  • apps/api
  • apps/zgrid-mobile

Relevant env vars:

  • R2_ACCOUNT_ID
  • R2_ACCESS_KEY_ID
  • R2_SECRET_ACCESS_KEY
  • R2_ATTACHMENTS_BUCKET

Where configured:

  • API env contract
  • API storage helper in apps/api/src/lib/r2.ts

Local / staging / prod notes:

  • local setup can omit it until attachment flows need real storage interaction
  • staging and production should use isolated environment-managed credentials and buckets

Cloudflare Email Routing​

Status:

  • Template-ready

Purpose:

  • placeholder slot for inbound or forwarding email setup documentation if the team operationalizes it

Used by:

  • not currently described as an active repo-standard integration

Relevant env vars:

  • none currently documented

Where configured:

  • external dashboard, not currently documented in repo detail

Local / staging / prod notes:

  • keep as placeholder-only until the repo/docs define a concrete operational dependency

Resend​

Status:

  • Implemented

Purpose:

  • transactional email provider for hosted environments

Used by:

  • apps/api

Relevant env vars:

  • EMAIL_PROVIDER
  • RESEND_API_KEY
  • EMAIL_FROM
  • EMAIL_REPLY_TO
  • EMAIL_SUPPORT_ADDRESS

Where configured:

  • API env contract
  • API email provider code under apps/api/src/features/email

Local / staging / prod notes:

  • local default should remain dev_log
  • staging/production expect EMAIL_PROVIDER=resend

Sentry​

Status:

  • Implemented

Purpose:

  • optional error monitoring and trace sampling

Used by:

  • apps/api
  • apps/manager-desk
  • apps/back-office
  • apps/zgrid-mobile

Relevant env vars:

  • SENTRY_ENABLED
  • SENTRY_DSN
  • SENTRY_ENVIRONMENT
  • SENTRY_RELEASE
  • NEXT_PUBLIC_SENTRY_*
  • EXPO_PUBLIC_SENTRY_*

Where configured:

  • app env loaders
  • environment-managed hosted settings

Local / staging / prod notes:

  • local should stay disabled unless intentionally testing delivery
  • staging and production may enable it when DSNs are provided

PostgreSQL Provider​

Status:

  • Implemented

Purpose:

  • primary application database

Used by:

  • apps/api

Relevant env vars:

  • DB_HOST
  • DB_PORT
  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DATABASE_URL

Where configured:

  • local Docker workflow
  • hosted environment secrets and vars

Local / staging / prod notes:

  • local commonly runs via Docker
  • hosted environments should use separate managed databases per environment

GitHub​

Status:

  • Implemented

Purpose:

  • source control, pull requests, Actions CI, and manual deploy workflow triggers

Used by:

  • whole repo

Relevant env vars:

  • GitHub Environment vars
  • GitHub Environment secrets

Where configured:

  • .github/workflows/ci.yml
  • .github/workflows/deploy.yml
  • repository settings / GitHub Environments

Local / staging / prod notes:

  • local development does not depend on GitHub being online once code is present
  • staging/production deploy flow depends on GitHub Actions plus environment configuration

GitHub Actions​

Status:

  • Implemented

Purpose:

  • CI validation and manual deployment orchestration

Used by:

  • whole repo

Relevant env vars:

  • environment contract values consumed by workflow steps

Where configured:

  • .github/workflows/ci.yml
  • .github/workflows/deploy.yml

Local / staging / prod notes:

  • local commands should mirror CI expectations where possible
  • deploy workflow currently targets Manager Desk and API explicitly

UptimeRobot​

Status:

  • Partial

Purpose:

  • optional uptime data source for Back Office system health views

Used by:

  • apps/back-office
  • API admin/system-health endpoints

Relevant env vars:

  • UPTIMEROBOT_API_KEY
  • UPTIMEROBOT_MONITOR_IDS

Where configured:

  • env contract
  • API system health service

Local / staging / prod notes:

  • if not configured, system health should show limited/unknown uptime information rather than failing the app

Lemon Squeezy​

Status:

  • Implemented

Purpose:

  • billing/subscription provider and webhook ingestion target

Used by:

  • apps/api

Relevant env vars:

  • billing-provider values documented in API env parsing and workflow code

Where configured:

  • API subscription service and webhook route

Local / staging / prod notes:

  • billing flows require hosted configuration to behave fully
  • do not document or commit provider secrets in repo docs

Related docs: