-   [](https://platform.exaloop.io/)
-   Production Deployment

# Production Deployment

Deploy an Exaloop application with its compatible native libraries, service configuration, and credentials. This guide covers runtime packaging, destination checks, database extensions, and rollback.

A build artifact and a deployed service have different requirements. Validate the complete package in an environment representative of the destination, including the services and data contracts it relies on.

## Build and Runtime Environments

The development distribution contains the compiler, CLI, SDKs, and code generators. A deployed native application needs its executable and runtime libraries, but not the compiler or the CLI's Python environment. Applications using explicit Python interoperability also need their Python environment on the destination.

The [platform requirements](https://platform.exaloop.io/releases/#platforms) apply to the deployment host as well as the build host. Database extensions have an additional dependency on their server's version and native ABI.

## Package an Application

For a project with an `app` target in `exaloop.toml`:

```sh title="Terminal"
exaloop --target app package --bundle-runtime --output packages/app-v1
```

The package contains the executable, native dependencies, integrity hashes, and license inventory. Its directory structure is part of the package: moving only the executable leaves its libraries behind. Libraries loaded dynamically can be included with `--runtime-library /absolute/path/to/library`.

Application data, TLS certificates, credentials, and external services are configured separately. In particular, the package does not supply a CA bundle or make certificate paths from the build machine portable.

## Production Checklist

| Area | Deployment check |
| --- | --- |
| Platform | Architecture, operating system, and libc meet the release requirements |
| Libraries | The complete runtime package runs on a clean destination without development-tool paths |
| Services | Database or Kafka versions, credentials, network access, and timeouts match the application configuration |
| Transport | Remote connections use verified TLS and the intended authentication mechanism |
| Data handling | Representative inputs cover nulls, malformed records, large batches, and schema changes |
| Recovery | Retries, redelivery, transaction failures, and process restarts have defined behavior |
| Capacity | Sustained traffic fits the available CPU, memory, and service limits |
| Observability | Application logs and service metrics distinguish processing failures from connectivity failures |
| Rollback | The previous application package and its compatible runtime remain available |

These checks are most useful in a staging environment that resembles the destination. A successful compiler invocation establishes that the code builds; it does not establish connectivity, permissions, or recovery behavior.

## Credentials and Diagnostics

Credentials belong in your deployment's secret-management mechanism, not in source files or command-line arguments. Verbose CLI output, process listings, profiling captures, and optimization logs can reveal arguments or local paths. Those artifacts may require redaction before sharing.

For Kafka, committing processed offsets and writing to an external service are separate operations unless the entire operation is covered by Kafka's transaction model. The [Kafka guide](https://platform.exaloop.io/streaming/kafka/#consume-and-commit) explains redelivery and the implications for idempotent processing.

## Database Extensions

Native server code executes with the database process's privileges. Its deployment therefore includes code review, restricted installation permissions, and staging tests for representative queries or commands. Loaded libraries must not be overwritten while a server is using them.

Host-specific installation and replacement procedures:

-   [DuckDB extensions](https://platform.exaloop.io/db/duckdb/deployment/)
-   [PostgreSQL functions](https://platform.exaloop.io/db/postgres/deployment/)
-   [MySQL functions](https://platform.exaloop.io/db/mysql/deployment/)
-   [Redis modules](https://platform.exaloop.io/db/redis/deployment/)

## Python Extensions

For a `python-extension` target, Exaloop builds an ABI-tagged wheel without a project `setup.py`:

```sh title="Terminal"
exaloop --target fastmath package --python .venv/bin/python --output packages/fastmath-v1
.venv/bin/python -m pip install packages/fastmath-v1/*.whl
```

The wheel includes the Codon runtime and other linked non-system native libraries in a distribution-specific directory. Loader paths are relative to the installed wheel, so the destination does not need the compiler or development installation. Exaloop distribution license inventories and build provenance are recorded under the wheel's `.dist-info` directory. Provide Python dependencies, application data, and libraries loaded dynamically separately, or explicitly include dynamic libraries with `--runtime-library`.

Match CPython's version and architecture to the wheel. These are native host wheels, not manylinux or stable-ABI wheels; validate the OS/libc baseline and SDK requirements on the destination. Test installation and representative calls in a clean Python environment before promotion. See the [Python-extension workflow](https://platform.exaloop.io/start/cli/#python-extensions) for target settings.

## Upgrades and Rollback

Updating the development distribution changes subsequent builds while leaving deployed applications in place. Rebuild against the new toolchain, verify behavior and resource use in staging, and deploy the resulting package through your normal release process.

[Project locks](https://platform.exaloop.io/start/distribution/#project-lock) record the distribution used by a project. Retaining the previous application package provides deployment rollback; `exaloop distribution rollback` changes the active development toolchain, not an already deployed service.

Source: https://platform.exaloop.io/production/