Customer builds and connector catalogs

Envoy can be compiled as a customer-specific Bun executable with a selected set of connectors and, when required, an approved connector catalog. This keeps the runtime self-contained and limits exposed capabilities to those intended for the deployment.

Build configuration is a release-engineering input, not an in-product connector configuration file.

Decide the capability set

Before requesting a build, inventory:

• connector types used by tasks and job templates;
• server and UI requirements;
• operating systems and CPU architectures;
• catalog integrations required for discovery or connected accounts;
• external files that must be mounted at runtime;
• licensing and distribution constraints.

Include every connector type referenced by a promoted bundle. Envoy rejects imported task definitions when their connector types are unavailable.

What the build produces

Depending on build options, the release can contain:

• one or more standalone executables;
• the embedded server and web UI;
• generated connector registration for the selected capability set;
• an approved catalog directory with integration definitions and documentation;
• deployment instructions for runtime paths.

The executable still receives environment-specific server configuration, secrets, database access, and connector records at deployment time.

Keep catalog and runtime configuration separate

Catalog assets describe available connector capabilities. Connector records identify a particular account and carry its non-secret settings and secret references.

Do not put customer credentials in:

• build configuration;
• catalog definitions;
• compiled assets;
• task or job-template YAML;
• release archives.

Verify a release

In a non-production environment:

1. verify executable checksum and platform;
2. start the control plane with a fresh test configuration;
3. confirm the expected connector types appear;
4. confirm unexpected or unapproved types do not appear;
5. open the catalog-backed connector forms;
6. create a test connector through the supported UI;
7. run one paged discovery request;
8. import representative tasks with dry-run enabled;
9. run a bounded end-to-end job;
10. record the release and catalog versions.

If a catalog path is mounted separately, verify that the runtime account can read it and that all executor instances receive the same version.

Upgrade planning

Treat a connector or catalog change as an application upgrade:

• review configuration-schema changes;
• verify renamed or removed methods;
• test pagination and field discovery;
• validate existing task definitions;
• test connected-account selection;
• preserve a rollback artifact;
• avoid mixing catalog versions across replicas.

Changing a catalog does not migrate stored connector records automatically. Review existing configurations after an upgrade.

See Catalog connectors and connected accounts, Seed import and upgrades, and Move tasks and job templates.