Seed import and upgrades

At startup, Envoy can import authored task and job-template definitions from configured directories. Customer builds can also seed curated AI references. Seeds initialize or update configuration records; they are not database backups.

Use seed files for definitions shipped with a deployment. Use NDJSON bundles for explicit promotion and review between running environments.

Seeded resources

The startup importer can process:

• task YAML from the configured tasks directory;
• job-template YAML from the configured jobs directory;
• approved AI reference Markdown from the customer seed location when a customer build is selected.

Connector credentials, instantiated jobs, connector bindings, job configuration values, runs, logs, users, sessions, and API keys are not seed content.

Startup behavior

The importer validates authored content before storing it. Task definitions are versioned when content changes. Existing runtime records are not reset merely because the server restarts.

Treat importer errors as deployment failures to investigate. A running process does not prove every intended definition imported successfully.

Prepare an upgrade

1. Read the release notes and schema changes.
2. Back up the application database and required external state.
3. Preserve the current executable, configuration, and catalog assets.
4. Export authored tasks and job templates as an additional review artifact.
5. Validate new seed definitions against the target build.
6. Confirm required connector types exist.
7. Test the upgrade against a copy of representative state.
8. Plan maintenance or traffic coordination for multi-replica deployments.

Never test an irreversible migration first against the only production database.

Deploy consistently

All control-plane replicas should use the same:

• executable version;
• schema version;
• seed content;
• connector catalog;
• branding assets;
• environment configuration.

During a rolling upgrade, prevent incompatible versions from concurrently mutating the same state unless that deployment pattern is explicitly supported.

Verify after upgrade

Check:

• server readiness;
• database migration completion;
• startup import summaries and errors;
• task and job-template versions;
• connector type availability;
• existing connector configuration forms;
• scheduled triggers;
• a bounded task and job run;
• dashboards, public shares, and AI references where enabled;
• log and metric persistence.

Existing jobs retain snapshotted task and template content. Upgrade a job only after reviewing the resolved diff and testing the replacement snapshot.

Rollback

An executable rollback may not reverse a database schema migration. Follow the release-specific rollback procedure and restore from a verified backup when required.

Do not delete volumes or application databases to force re-seeding. That destroys operational state and is not an upgrade mechanism.

See Customer builds and connector catalogs and Task and job bundles.