# Customer builds and connector catalogs

> Source: https://docs.clonepartner.com/deployment/customer-builds-and-catalog/

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](/connectors/catalog-and-connected-accounts), [Seed import and upgrades](/deployment/seed-import-and-upgrades), and [Move tasks and job templates](/guides/task-and-job-bundles).