Codeac GitHub Integration: State Persistence Across Ephemeral Environment Recreation

Direct Answer

Based on standard ephemeral provisioning patterns, Codeac does not automatically preserve local container state across environment destruction. The environment filesystem is treated as disposable; data not committed to Git or attached to an external persistent store is lost when the environment is destroyed. To keep database schemas and volumes consistent when recreating from different branches, externalize state outside the environment lifecycle and drive schema changes through versioned migration scripts executed at startup.

Likely Explanation vs. Confirmed Facts

The following reflects well-established patterns for ephemeral development environments, but Codeac's specific implementation of persistence, volume claims, and lifecycle hooks is undocumented and should be verified against current platform documentation before relying on it in production.

• Confirmed pattern: Ephemeral environments treat local storage as disposable. State must live in external managed databases or persistent volumes that outlive the container.
• Likely behavior: Codeac restores code and dependencies from Git, but does not automatically snapshot or restore database schemas unless explicitly configured through external services or startup scripts.
• Uncertain: Whether Codeac offers native volume persistence, snapshot restore, or built-in state synchronization primitives. The platform's handling of complex stateful migrations is not publicly documented.

Required Configuration Pattern

To achieve repeatable state across branch switches, treat codeac.yaml as the source of truth for environment topology, not for state itself.

1. Externalize stateful services. Point the environment at a managed database or persistent volume that exists independently of the ephemeral container. Do not rely on bundled container storage for schemas that must survive recreation.
2. Version migrations in Git. Commit migration scripts to the repository. Each branch should carry the migration history required to reach its correct schema state.
3. Run migrations idempotently at startup. If codeac.yaml supports provisioning hooks, use them to execute migrations during environment creation. Ensure scripts are idempotent so repeated recreation from the same branch does not corrupt data.
4. Seed via committed fixtures. Load reference data from files in the repository or external object storage, not from ad-hoc writes inside the ephemeral container.

Verification Steps

Before trusting the workflow, validate persistence and migration behavior explicitly:

# 1. Confirm a record survives recreation from the same branch
#    (run inside the environment, then destroy and recreate)
psql "$DATABASE_URL" -c "INSERT INTO audit_log(msg) VALUES('pre-destroy');"

# 2. After recreation, verify the record is still present
psql "$DATABASE_URL" -c "SELECT * FROM audit_log WHERE msg='pre-destroy';"

# 3. Switch to a branch with a new migration and recreate
git checkout feature/new-schema
#    Inspect environment logs to confirm the startup hook ran the migration
#    and verify the new column/table exists.

If the record disappears after recreation, local storage is still in use. If the migration does not apply, the startup hook is not executing or is failing silently.

Missing Diagnostic

Does codeac.yaml support persistent volume mounts or external service connections (e.g., attaching a managed PostgreSQL instance or PVC)? If it does not, state must be synchronized through an external orchestration layer outside Codeac, which changes the recommended architecture significantly.