oxynote/e2e/docker-compose.prod.yaml

# the production all-in-one image under test, with the backing services a
# real deployment gives it. This is docker/prod/docker-compose.example.yaml
# — the deployment the README documents — retuned for a test run.
#
# it differs from docker-compose.dev.yaml (the dev stack) in what it is testing,
# not in how: there, four containers built from this checkout; here, the one
# image an operator actually pulls, with caddy, web, core and auth-realtime
# supervised inside it. Everything the suite asserts about the product must
# hold for both.
#
# the same fixture rules apply:
#   - no named volumes, so every run starts from an empty database and an
#     empty data volume (the generated secrets are regenerated per run)
#   - no container_name, and its own ports (:19080 front door, :19081 the
#     instance without email, :19082 the single-workspace instance, :19025
#     mailpit), so it coexists with the dev stack and the e2e dev stack
#     alike
#   - env is inlined and committed; there is nothing secret to protect
#   - every image is pinned
#   - no OXYNOTE_DB_DSN, OXYNOTE_VALKEY_DSN or OXYNOTE_OBJECT_STORAGE_DSN, which
#     is the default single-node deployment: the image runs its own
#     PostgreSQL, the assistant keeps its conversations in the core process,
#     better-auth keeps no secondary storage, and uploaded images live on the
#     data volume
#
# the image is built by `make prod-build`, not by compose: core's binary has
# to come from goreleaser and be staged for the Dockerfile's COPY, so there
# is no build section here to point at. `make e2e-prod-stack-build` tags it
# :e2e-prod, so a run cannot replace the :prod image `make prod-run` uses.

name: oxynote-e2e-prod

services:
  oxynote:
    image: ghcr.io/oxynote/oxynote:e2e-prod
    ports:
      - "19080:8080"
    environment:
      - OXYNOTE_PUBLIC_URL=http://localhost:19080
      - OXYNOTE_SMTP_DSN=smtp://mailpit:1025?tls=none
      - OXYNOTE_EMAIL_FROM_ADDRESS=Oxynote <team@oxynote.io>
      - OXYNOTE_MAX_ORGANIZATION_MEMBERS=5
      # every test signs up and creates its own workspace, and a stack left
      # up for a day of iteration would hit a lower cap and start failing
      # signups with a full-house message.
      - OXYNOTE_MAX_ORGANIZATIONS=100000
      # every request in a run arrives from one address, and better-auth
      # gives sign-in and sign-up three per ten seconds between them, so the
      # limiter would fail the suite rather than the code under test.
      - OXYNOTE_RATE_LIMIT_DISABLED=true
    # the image ships its own layered probe (every internal service plus the
    # front door), which is what the probe container and the tests wait on.
    # Its start period is three minutes; compose inherits that.
    #
    # the image shuts its services down in order, flushing open documents
    # last, and docker's default 10s grace would SIGKILL that mid-flush.
    stop_grace_period: 60s

  # the same image with no email sender, which is all it takes to run the
  # product without email: the launcher derives the switch from the missing
  # OXYNOTE_SMTP_DSN. tests/prod-without-email.test.ts drives it through its
  # own front door; every other test stays on the instance above.
  oxynote-without-email:
    image: ghcr.io/oxynote/oxynote:e2e-prod
    ports:
      - "19081:8080"
    environment:
      - OXYNOTE_PUBLIC_URL=http://localhost:19081
      - OXYNOTE_MAX_ORGANIZATION_MEMBERS=5
      # the same two allowances as the instance above, for the same reasons.
      - OXYNOTE_MAX_ORGANIZATIONS=100000
      - OXYNOTE_RATE_LIMIT_DISABLED=true
    stop_grace_period: 60s

  # the same image with the workspace limits left at their defaults: one
  # workspace, created with its admin at boot, and signup by invitation
  # only. tests/prod-single-workspace.test.ts drives it through its own
  # front door. Its tests share that one workspace, so no other test may
  # use this instance.
  oxynote-single-workspace:
    image: ghcr.io/oxynote/oxynote:e2e-prod
    ports:
      - "19082:8080"
    environment:
      - OXYNOTE_PUBLIC_URL=http://localhost:19082
      - OXYNOTE_SMTP_DSN=smtp://mailpit:1025?tls=none
      - OXYNOTE_EMAIL_FROM_ADDRESS=Oxynote <team@oxynote.io>
      # the same limiter allowance as the instance above.
      - OXYNOTE_RATE_LIMIT_DISABLED=true
    stop_grace_period: 60s

  # a sibling on the private network, and the only honest way to ask the
  # question the trust boundary answers: can a container that is not caddy
  # reach core, auth-realtime or the web server directly? The prod tests
  # drive it with `docker compose exec` — see helpers/prod.ts.
  #
  # probing published host ports instead would prove nothing: the internal
  # ports are not published, so every such probe would pass whether the
  # services bound loopback or the wildcard.
  probe:
    image: alpine:3.24.2
    command: ["sleep", "infinity"]
    depends_on:
      oxynote:
        condition: service_healthy

  # the tests read verification links out of mailpit's REST API, so its http
  # port is published rather than proxied through the image's front door —
  # which routes nothing but the product.
  mailpit:
    image: axllent/mailpit:v1.31.3
    environment:
      - MP_QUIET=true
    ports:
      - "19025:8025"