Domains, SSL & Security
Custom domains, automated Let's Encrypt TLS via Caddy, maintenance mode, and token security
Custom Domains, SSL & Platform Security
Explita Deploy pairs Docker containers with Caddy—an edge reverse proxy that automatically provisions and renews TLS certificates via Let's Encrypt and ZeroSSL.
1. Custom Domains & Automated SSL
Attaching a Domain
To attach a custom domain (apex or subdomain) to your application:
eda domain add app.example.comDNS Configuration
Before attaching your domain, point your DNS records to your host server's public IP address:
| Record Type | Host / Name | Target / Value |
|---|---|---|
| A | @ (or app) | <your-vps-ip-address> |
| CNAME | www (or subdomain) | app.example.com (or @) |
Verifying DNS & SSL Status
Verify that DNS resolution has propagated and that Caddy has successfully obtained a TLS certificate:
eda domain check app.example.com
# Alias: eda domain verify app.example.comListing & Removing Domains
# List all attached domains
eda domain ls
# Remove a domain
eda domain rm app.example.com2. Zero-Downtime Traffic Swapping
Under the hood, Explita Deploy communicates directly with Caddy's dynamic administration API (http://127.0.0.1:2019):
- Pre-flight Probing: When a new deployment starts, Caddy does not touch live traffic until the new container returns
200 OKon its configured health check route. - Atomic Route Swap: Caddy's routing configuration is updated in memory using an atomic JSON patch. Active HTTP connections are allowed to complete on the old container, while all new incoming connections immediately route to the new container.
- Graceful Container Drain: The previous container remains running for a configurable drain window before being stopped, preventing 502 Bad Gateway errors during high-traffic deployments.
3. Instant Maintenance Mode (eda maintenance)
When performing breaking schema migrations, emergency maintenance, or offline data operations, you can place your application into maintenance mode with a single command:
eda maintenance onHow Maintenance Mode Works:
- Incoming HTTP requests across all attached custom domains and tunnels immediately receive an HTTP
503 Service Unavailableresponse with a responsive, branded maintenance splash screen. - Your container and database remain running: The application container is not stopped. You can still run remote administrative commands, inspect files, or run migrations using
eda execandeda sh.
Checking Status & Restoring Traffic
# Check maintenance status
eda maintenance status
# Restore live traffic
eda maintenance off4. Platform Security & Authentication
Explita Deploy is engineered with multiple defensive layers to protect your infrastructure:
1. Bearer Token Authentication (DEPLOY_TOKEN)
All communication between the local developer CLI (eda) and the remote host server is authenticated via bearer tokens. The token is generated randomly during host installation and stored in /opt/explita/deploy/.env.
Update your local CLI config:
eda config set token <DEPLOY_TOKEN>2. Zero-Disk Static Passcode / PIN Protection
To protect your server in case an unauthorized person gains physical or file access to your local machine's stored token, you can enforce a secondary passcode:
In the server's .env:
DEPLOY_PASSCODE=secret-pin-9876Security Boundary: You Only Know The Passcode
Unlike tokens and server URLs, passcodes are strictly forbidden from being saved to configuration files (they are never written to explita.json or ~/.explita/config.json, and only you know them).
When executing protected or administrative operations against an authenticated server, eda prompts you securely in your terminal:
🔑 Enter deploy passcode / PIN:For non-interactive automation or single sensitive commands, you can supply it inline in memory:
eda promote d79 --pass secret-pin-9876The passcode is held strictly in session memory for that command invocation and is never written to disk.
3. AES-256 Encryption at Rest
All environment variables configured with eda env set are encrypted using authenticated AES-256 before being written to the database using the server's APP_ENCRYPTION_KEY. Plaintext secrets are never stored in unencrypted server tables.