coder13 / coder13/LetsCube

Support an isolated beta/staging environment

Offen
#181 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
JavaScript
Sterne
30
Forks
9
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

## Goal

Add a beta/staging environment where changes can be tested without disrupting active production races.

## Current constraints

The production host currently has:

- 1 vCPU
- 1.9 GiB RAM with no swap
- About 738 MiB available RAM during normal operation
- About 505 MiB used by the existing Docker containers
- About 14 GiB free disk space after routine cleanup

Normal beta traffic would be negligible. The main constraints are the fixed memory cost of duplicated services and contention from building images on the single CPU. A fully duplicated stack would add roughly 500 MiB at idle, leaving too little safety margin on the current host.

## Recommended direction

Prefer a fully isolated beta stack on a separate small VPS. This keeps beta deployments, migrations, restarts, memory spikes, and broken builds from affecting production. An on-demand VPS that is stopped when unused could keep the cost low.

If beta must share the production host, first resize it to at least 4 GiB RAM, add service resource limits, and build images in CI rather than on the server.

## Likely implementation work

- Add beta.letscube.net, TLS, and a separately registered WCA OAuth callback.
- Parameterize the Compose project name and currently single-environment deployment script.
- Use separate secrets, sessions, Mongo database, PostgreSQL database, Redis namespace or instance, and migration target.
- Configure beta API, Socket.IO, CORS, and client build origins.
- Separate deployment locks, logs, image and rollback tags, health checks, and backups.
- Prefer CI-built images that each environment pulls and deploys.
- Document beta deployment, rollback, reset, and data-seeding procedures.

## Rough effort

- Minimal usable environment: 1–2 focused days.
- Polished setup with CI image builds, verified rollback, documentation, and end-to-end testing: 2–4 days.

## Alternative options

- Run beta API/socket processes against logically isolated databases on the current host: lower memory use, but it shares production failure modes.
- Run a fully isolated beta stack on demand on the current host: workable only with careful resource management and still risks production contention.
- Host only a beta client against production: very low effort, but it does not safely test backend, protocol, migration, or deployment changes.

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Beginne damit, die Compose-Konfiguration und das derzeit einzige Deployment-Skript für eine Umgebung zu lokalisieren, und verfolge anschließend die API, Socket.IO, die Client-Build-Origins, Secrets und Datenbankziele. Die Aufgabe ist abgeschlossen, wenn beta über isolierte Deployment- und Datenressourcen, Rollback- und Health-Check-Behandlung sowie dokumentierte Verfahren für Deployment, Reset und Data-Seeding verfügt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
docker, docker-compose, javascript, mongodb, node.js, postgresql, react, redis
Bereich
api, backend, ci-cd, cloud, databases, devops, documentation, infrastructure
Issue-Typ
Feature
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
42/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.