Deployment and operations
What a self-hosted deployment needs, how hosts are provisioned and configured, which variables each service reads, and how operators update, schedule, back up and recover the platform. Browse the feature map or configuration finder.
Availability: Next. Entries that depend on an optional feature, a role or a deployment choice name it in their own Availability line.
Features in this family
- Deployment prerequisites
- AWS access and instance profile
- Container images and release tags
- Provision and bootstrap hosts
- First-use setup and baseline data
- Service roles and topology
- Environment variable reference and deployment identity
- Configuration layers and activation
- Apply an update to the hosts
- Release compatibility and upgrade notes
- Service refresh and server group maintenance
- Sync platform and app configuration to Redis
- Background jobs and schedules
- Configuration snapshots and backups
- Recover deployment configuration
- Database backups and restore
- Database connection and credentials
- Redis connection
- Voice service operation
- Legal notice banner
- Platform settings
- Deployment feature switches
- Enabled features overview
- Portal feature profiles
- Portal configuration publishing
Deployment prerequisites
A deployment needs hosts for each role on a supported operating system, DNS names for the public endpoints, registry and cloud access and an agreed set of open ports before provisioning starts.
For: Deployment operators
Read more:
- Reference: Hosts and roles
- Reference: Host operating system
- Reference: DNS names and certificates
Related features: AWS access and instance profile, Provision and bootstrap hosts, Network ports, allowed sources and firewall.
AWS access and instance profile
Hosts reach the container registry, configuration bucket and Secrets Manager with an EC2 instance profile by default, or with static keys or key files where no instance profile exists.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Host environment, AWS variables(AWS_USE_INSTANCE_PROFILE, AWS_REGION, AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) | Bootstrap variables |
Read more:
- Reference: Diagnose an EC2 instance-profile connection
- Reference: Verify the host's AWS permissions
- Reference: Registry and cloud access
Related features: Deployment prerequisites, Container images and release tags, Platform secrets and secret storage.
Container images and release tags
Service images are pulled from a private registry by release tag, and every service reports its build version and date so operators can confirm which release is running.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Bootstrap environment, registry and tag variables(ECR_REGISTRY, ECR_TAG, APP_VERSION, BUILD_DATE) | Bootstrap variables |
Read more:
- Reference: Registry and cloud access
- Reference: Keep four identities separate
Related features: Release compatibility and upgrade notes, Apply an update to the hosts, AWS access and instance profile.
Provision and bootstrap hosts
Hosts are created in a fixed order, receive a bootstrap file with their role and environment, fetch their configuration bundle from the bucket and run the role init with retries.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Host bootstrap file(CONFIG_BUCKET, CONFIG_BASE_PATH, CONFIG_REF, SERVER_ROLE, FETCH_CONFIG_ATTEMPTS, FETCH_CONFIG_RETRY_DELAY) | Write the bootstrap file |
Read more:
- Set it up: Plan the provisioning order
- Reference: Write the bootstrap file
- Set it up: Understand host initialization
- Reference: Fetch the configuration bundle
- Set it up: Run role initialization
- Troubleshoot: Retry a failed initialization
Related features: First-use setup and baseline data, Deployment prerequisites, Environment variable reference and deployment identity, Portal configuration publishing.
First-use setup and baseline data
After the first start, a setup command creates the first operator, team and base number and loads baseline data, and it can also run unattended from setup variables.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Setup command and unattended setup variables(DELPHI_SETUP_EMAIL, DELPHI_SETUP_PASSWORD, DELPHI_SETUP_TEAM_NAME, DELPHI_SETUP_BASE_NUMBER, RUN_BASELINE_SEED) | Run first-use setup |
Read more:
- Set it up: Run first-use setup
- Reference: Bootstrap and migration credentials
Related features: Provision and bootstrap hosts, Database connection and credentials.
Service roles and topology
The platform splits into web, API, edge, voice, media, operations, database and observability roles, each with its own containers and network responsibilities; some components are optional or run outside the deployment.
For: Deployment operators, Integrators
Read more:
- Reference: Role catalogue
- Reference: Optional, local and separately managed components
- Reference: Configuration and network ownership
Related features: Deployment prerequisites, Environment variable reference and deployment identity, Voice service operation.
Environment variable reference and deployment identity
One reference lists the variables each role reads, including the environment name, host name, public domains and runtime mode shared by all services, and marks which ones changed between releases.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment files per role(ENVIRONMENT, HOSTNAME, NODE_ENV, DOMAIN_API, DOMAIN_TELWEB, NEXT_PUBLIC_SIP_DOMAIN, PORT, HOST) | Shared runtime variables |
Read more:
- Reference: Shared runtime variables
- Reference: Bootstrap variables
- Reference: Changes in 0.9.19
- Set it up: Verify the effective values
Related features: Configuration layers and activation, Service roles and topology, Provision and bootstrap hosts.
Configuration layers and activation
A setting lives in exactly one layer, such as the bootstrap file, the service environment, platform settings or a team record, and each layer needs its own activation step from a live reload to a container restart.
For: Deployment operators
Read more:
- How it works: 2. Place configuration in the correct layer
- Reference: Choose the affected consumers
- Troubleshoot: 7. Recover at the failed layer
Related features: Environment variable reference and deployment identity, Service refresh and server group maintenance, Platform settings.
Apply an update to the hosts
Operators roll a new release or configuration change out host by host, check each role before moving on and keep the previous tag available for rollback.
For: Deployment operators
Read more:
- Set it up: 5. Apply the intended change
- Troubleshoot: 7. Recover at the failed layer
Related features: Release compatibility and upgrade notes, Container images and release tags, Configuration layers and activation.
Release compatibility and upgrade notes
A release tag, the deployment manifest, the running image and the declared upstream versions answer different questions, and the page lists the extra steps each upgrade needs, including the Portal.
For: Deployment operators, Integrators
Read more:
- Reference: Keep four identities separate
- Set it up: Upgrade to 0.9.19
- Set it up: Upgrade the separately managed Portal
- Reference: Declared upstream versions
- Reference: Defaults, overrides and mutable references
Related features: Apply an update to the hosts, Container images and release tags.
Service refresh and server group maintenance
Platform administrators push the current configuration to running services or put a server group into maintenance from one admin page, and see the result of the last refresh.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Server Groups › Maintenance(/admin-settings/server-groups/maintenance, /admin-settings/service-refresh) | Refresh running services deliberately |
Read more:
- Set it up: Refresh running services deliberately
- Set it up: Target one server group
Related features: Configuration layers and activation, Sync platform and app configuration to Redis, Background jobs and schedules.
Sync platform and app configuration to Redis
Routing, trunk and application data are published from the database to Redis for the edge and voice services, either automatically on save or on demand with a sync action.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Sync Platform to TelPro(redisSync.syncAll, REDIS_SYNC_TIMEOUT_SECONDS) | Save, activate, disable or delete safely |
Read more:
- Set it up: Save, activate, disable or delete safely
Related features: Service refresh and server group maintenance, Redis connection.
Background jobs and schedules
The operations service runs recurring jobs such as backups, certificate renewal, cleanup and evidence persistence under leader election, and administrators view, change or trigger schedules and read the job history.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Cron Schedules(/admin-settings/cron-schedules, /admin-settings/job-history) | 4. Change a recurring schedule deliberately |
| Services and containers | Tasker environment, worker and leader variables(WORKER_CONCURRENCY, WORKER_POLL_INTERVAL_MS, SCHEDULER_POLL_INTERVAL_MS, LEADER_ELECTION_KEY, LEADER_LOCK_TTL_MS) | Ops variables |
Read more:
- Set it up: 1. Find the responsible job
- Troubleshoot: 3. Distinguish scheduler failure from worker delay
- Set it up: 4. Change a recurring schedule deliberately
Related features: Database backups and restore, Public edge certificates and renewal, Operation events, Service refresh and server group maintenance.
Configuration snapshots and backups
Platform administrators save named snapshots of platform configuration, compare and restore single domains or everything, and export or import a configuration bundle between deployments.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Config Backups(/admin-settings/config-backups) | Snapshot or backup: which asset fits |
Read more:
- How it works: Snapshot or backup: which asset fits
- Reference: What a platform configuration bundle contains
- Set it up: Record and restore one kind of entity
- Reference: Understand what Restore and Import change
- Reference: Find a row's history
Related features: Recover deployment configuration, Database backups and restore.
Recover deployment configuration
Before a risky change, operators record the bootstrap files, environment files and image tags of each host, and restore them to bring a host back to its last known good state.
For: Deployment operators
Read more:
- Set it up: Capture a recoverable deployment change
- Set it up: Restore only the changed layer
Related features: Configuration snapshots and backups, Database backups and restore, Apply an update to the hosts.
Database backups and restore
A scheduled job dumps the platform database to S3 every six hours under an environment prefix, and operators verify the dump and restore it into a clean database.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Tasker environment, backup target variables(backup-database, S3_BUCKET, S3_PREFIX, S3_REGION, S3_ENDPOINT) | Database backup and restore |
Read more:
- Set it up: Database backup and restore
- Set it up: Verify what the backup job produced
Related features: Background jobs and schedules, Configuration snapshots and backups, Database connection and credentials.
Database connection and credentials
Services read the database connection from a URL or from an AWS secret that they refresh on rotation, while migrations and setup use a separate privileged connection through the pooler.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, database variables(DATABASE_URL, DATABASE_SECRET_MODE, DATABASE_SECRET_ARN, MIGRATION_DATABASE_URL, DATABASE_POOL_SIZE) | Select the runtime credential source |
Read more:
- Reference: Select the runtime credential source
- Reference: Choose a supported secret payload
- Reference: Understand automatic refresh
- Set it up: Plan and verify a runtime rotation
- Reference: Bootstrap and migration credentials
- Reference: Database variables
Related features: Encrypted database and Redis connections, Database backups and restore, First-use setup and baseline data.
Redis connection
All runtime services share one Redis for routing data, call state and locks, configured by host, port, credentials and database index.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, Redis variables(REDIS_HOST, REDIS_PORT, REDIS_USERNAME, REDIS_PASSWORD, REDIS_DATABASE) | Shared runtime variables |
Read more:
- Reference: Shared runtime variables
Related features: Encrypted database and Redis connections, Sync platform and app configuration to Redis.
Voice service operation
The voice role pairs Asterisk with the conversation runtime over ARI, reports a heartbeat, enforces ARI session limits and can be drained before a restart so active calls finish.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Voice host environment, Asterisk and ARI variables(ARI_URL, ARI_USER, ARI_PASS, ARI_APP, ARIHTTPSESSIONLIMIT, EXTERNALADDRESS) | Roles and the ARI connection |
Read more:
- How it works: Roles and the ARI connection
- Reference: ARI session limits
- Reference: Heartbeat and call admission
- Reference: AudioProc
- Set it up: Restart and drain a Voice host
- Reference: Voice variables
Related features: Voice service and media diagnostic logs, Service health and readiness checks, Alert rules and voice service heartbeat, Service roles and topology.
Legal notice banner
A deployment can show a fixed legal or usage notice on the public web pages, given either as plain text or as trusted HTML that takes precedence.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Web service environment, banner variables(LEGAL_BANNER_TEXT, LEGAL_BANNER_HTML) | Web variables |
Read more:
- Reference: Web variables
Related features: Environment variable reference and deployment identity.
Platform settings
Platform administrators manage deployment-wide defaults such as secret storage, model defaults, observability, media cache, egress, transfer restrictions and edge certificates on one admin page.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Platform settings | Admin Settings › Platform Settings(/admin-settings/platform-settings, platformSecrets, llmDefaults, qaScoring, signoz, ttsMediaCache, egressDefaults, transferRestrictions, resilienceDefaults, mediaConnection, sensitiveStorage, edgeTls, languageDetection) | Other Platform Settings controls |
Read more:
- Reference: Other Platform Settings controls
- Reference: Feature-dependent cards and save boundaries
Related features: Platform secrets and secret storage, SigNoz connection for the web application, Public edge certificates and renewal, Configuration layers and activation.
Deployment feature switches
Optional product areas are switched on or off per deployment with feature variables; the services read them at start and the web application receives the effective set from its runtime configuration endpoint.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Services and containers | Service environment, FEATURE_* variables(FEATURE_SMS, FEATURE_BROWSER_SDK, FEATURE_WEBRTC, FEATURE_RESILIENCE, FEATURE_QA_SCORING) | Deployment choices and effective service configuration |
Read more:
- How it works: Deployment choices and effective service configuration
- Set it up: Apply and verify an intended change
Related features: Enabled features overview, Portal feature profiles, Configuration layers and activation.
Enabled features overview
Team members see which optional features their deployment has switched on from a read-only settings page, which helps separate a missing feature from a missing permission.
For: Team administrators, Application builders
| Level | Where to change it | Owner section |
|---|---|---|
| Team settings | Settings › Features(/settings/features) | See which features are enabled |
Read more:
- Reference: See which features are enabled
Related features: Deployment feature switches.
Portal feature profiles
For deployments managed through the Portal, the vendor keeps a saved feature profile per deployment, and activating a profile changes the feature variables written into the next configuration bundle.
Availability: Managed deployments only.
For: Deployment operators
Read more:
- How it works: Release profiles in the Portal
Related features: Portal configuration publishing, Deployment feature switches.
Portal configuration publishing
The Portal keeps a registry of customer deployments and generates each deployment's configuration bundle into its bucket, which the hosts then fetch during bootstrap.
Availability: Managed deployments only.
For: Deployment operators
| Level | Where to change it | Owner section |
|---|---|---|
| Portal and feature profiles | Portal › Deployments(CONFIG_BUCKET, AWS_ACCOUNT_ID, DELPHI_PLATFORM_ROLE_ARN, DELPHI_EXTERNAL_ID) | Optional, local and separately managed components |
Read more:
- How it works: Optional, local and separately managed components
- Reference: Fetch the configuration bundle
Related features: Portal feature profiles, Provision and bootstrap hosts.