fly.toml

# fly.toml app configuration file generated for SourceBox Sentry Command
#
# See https://fly.io/docs/reference/configuration/ for information about settings

app = "opensentry-command"
primary_region = "sjc"

[build]

[env]
  FRONTEND_URL = "https://opensentry-command.fly.dev"
  DATABASE_URL = "sqlite:////data/opensentry.db"
  # Segment-cache ceiling MUST stay well under [[vm]].memory_mb below —
  # above physical RAM, the kernel OOM-killer fires (killing every
  # org's streams at once) long before the cache's own eviction can.
  # 384 MiB on the 1 GiB machine leaves ~600 MiB for Python + SQLite
  # (~25 concurrent live cameras). Scale this and memory_mb TOGETHER.
  SEGMENT_CACHE_MAX_TOTAL_BYTES = "402653184"

[[mounts]]
  source = "opensentry_data"
  destination = "/data"

[deploy]
  # CI uses build-image-then-`fly machine update` (see
  # .github/workflows/deploy.yml) which doesn't honour this strategy
  # — it goes straight to the in-place machine API.  This block
  # only matters if someone runs plain `fly deploy` manually.
  # `immediate` is the closest match for our single-machine +
  # single-volume topology: rolling tries to provision a parallel
  # machine and errors on the volume's single attachment slot.
  # The path to zero-downtime deploys is migrating off
  # SQLite-on-a-single-volume (Postgres or LiteFS).
  strategy = "immediate"

[http_service]
  internal_port = 8000
  force_https = true
  auto_stop_machines = "off"
  auto_start_machines = true
  min_machines_running = 1
  processes = ["app"]

  [[http_service.checks]]
    grace_period = "30s"
    interval = "10s"
    timeout = "5s"
    method = "GET"
    path = "/api/health"

[[vm]]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 1024