v2-platform: 11 sandbox image — same Dockerfile, PGlite/Neon tiering at the DB seam

Open
#285 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, postgresql, typescript

Research direction

Start at the existing DB driver seam and the Dockerfile/image configuration, then read parent issue #274 and the blocked OTA watch runtime work in #284. Done means one image boots and serves with either embedded PGlite or remote Neon, runs migrations, supports default watch mode, and passes a Docker smoke test for both engines.

Written by the indexing model from the issue text.

Description

ready-for-agent

Parent

#274 (v2 platform services spec)

What to build

The sandbox image: the same static container image as every production host, boot-parameterized only by account and gateway env, running watch mode by default. The database tiering lands here at the existing DB driver seam: PGlite embedded (same Postgres dialect as dev/test/prod — the repo already runs PGlite for tests) selected by config for disposable sandboxes, Neon for production, one image for both. A docker smoke test proves the image boots per-account and serves. Memory posture: the app process is the floor (~300–500MB); PGlite adds bounded tens of MB.

Acceptance criteria

  • The production Docker image boots with only account/gateway/DB-engine env differences and serves the account's app
  • PGlite engine: a sandbox boots with an embedded database, runs migrations, and serves — zero external DB dependencies
  • Neon engine: the same image boots against a provisioned remote database unchanged
  • A docker smoke test covers boot-and-serve for both engines
  • Watch mode runs by default in the sandbox tier (config change → app updates, no restart)

Blocked by

  • #284 (OTA watch runtime)
Dominant language
TypeScript
Stars
5
Forks
6
Avg merge
1m
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NEARBuilders/everything-dev

All issues in NEARBuilders/everything-dev

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.