Skip to main content

External Services Overview

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

ZGRID relies on a small set of external platforms for hosting, storage, delivery, monitoring, and billing. This page focuses on purpose, ownership, config touchpoints, and safe environment notes.

How to Read This Page​

This is the integration map for the public docs.

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

What this means in practice:

  • Render is the hosted runtime home of the shared API layer
  • it is infrastructure, not a separate product surface

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/landing
  • apps/manager-desk
  • apps/back-office in hosting docs

Relevant env vars:

  • VERCEL_TOKEN
  • VERCEL_ORG_ID
  • VERCEL_PROJECT_ID_MANAGER_DESK
  • landing contact-form vars in the landing Vercel project
  • 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
  • landing preview/staging should use a preview subdomain first
  • landing production can later attach zgrid.app and www.zgrid.app
  • Manager Desk deploy automation is documented
  • Back Office Vercel hosting is documented, but a dedicated deploy step is not currently shown in repo automation

What this means in practice:

  • Vercel is where the web surfaces live
  • landing, Manager Desk, and Back Office remain separate surfaces even when they share the same hosting family

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

What this means in practice:

  • Expo/EAS is the mobile delivery layer, not the mobile business-logic layer
  • product rules still live in the shared API contract

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

What this means in practice:

  • attachment binaries live outside the application database
  • application state and attachment metadata still stay under API control

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
  • apps/landing

Relevant env vars:

  • EMAIL_PROVIDER
  • RESEND_API_KEY
  • EMAIL_FROM
  • EMAIL_REPLY_TO
  • EMAIL_SUPPORT_ADDRESS
  • CONTACT_EMAIL_TO
  • CONTACT_EMAIL_FROM

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
  • landing contact delivery also uses RESEND_API_KEY, CONTACT_EMAIL_TO, and CONTACT_EMAIL_FROM

What this means in practice:

  • ZGRID keeps delivery provider concerns behind environment-managed boundaries
  • product surfaces can rely on email flows without hardcoding provider details

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:

  • SaaS subscription billing provider and webhook ingestion target for manager organizations

Used by:

  • apps/api

Relevant env vars:

  • LEMON_SQUEEZY_ENABLED
  • LEMON_SQUEEZY_TEST_MODE
  • LEMON_SQUEEZY_ALLOW_TEST_MODE_IN_PRODUCTION
  • LEMON_SQUEEZY_API_KEY
  • LEMON_SQUEEZY_STORE_ID
  • LEMON_SQUEEZY_WEBHOOK_SECRET

Where configured:

  • API subscription service and webhook route

Local / staging / prod notes:

  • billing flows require hosted configuration to behave fully
  • current scope is Zgrid SaaS subscription billing for upravitelji/manager organizations
  • do not treat Lemon Squeezy as the resident invoice payment provider
  • do not document or commit provider secrets in repo docs

Monri​

Status:

  • Partial

Purpose:

  • planned resident invoice payment provider target for one-time card-payment flows

Used by:

  • API resident payment provider selection paths
  • mobile and manager payment UX as a future real-provider target

Relevant env vars:

  • RESIDENT_PAYMENT_PROVIDER
  • RESIDENT_PAYMENT_MOCK_ENABLED

Where configured:

  • API resident payment provider registry and env parsing

Local / staging / prod notes:

  • current resident payment flow should be documented as mock/staging-provider oriented unless a real provider is explicitly enabled and implemented
  • do not claim Monri is live in production
  • do not claim recurring resident card payments exist
  • do not claim split payments are supported

Related docs: