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 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:
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 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:
Python Extensions
For a python-extension target, Exaloop builds an ABI-tagged wheel without a
project setup.py:
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 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 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.