Temps 0.0.7: Docker Compose, Edge CDN, Content-Addressable Storage, and Email Tracking

Temps 0.0.7 is our biggest release yet — 100 commits across two weeks that add six major features to the platform. Docker Compose is now a first-class deployment preset. Edge CDN nodes can cache your static assets globally. Email tracking tells you who opened what. And you can now exec into running containers directly from the dashboard.

If you're new to Temps, start with what Temps is and why we built it. Otherwise, here's everything that shipped.

TL;DR: Temps 0.0.7 adds Docker Compose as a deployment preset with multi-service domain routing, a Pingora-powered Edge CDN proxy with ECIES-encrypted TLS distribution, content-addressable static asset storage with SHA-256 deduplication, WebSocket-based container exec terminals, email open/click tracking with 116 tests, and three new CLI deploy commands (image, static, git).

What Changed in Docker Compose Deployments?

Docker Compose went from "not supported" to a first-class deployment preset across 35 commits in 0.0.7. You can now deploy multi-container apps via git-push with a DownloadRepo → DeployCompose → MarkComplete pipeline — the same workflow you already use for Next.js, Vite, or Dockerfile projects.

The Docker Compose support isn't a bolted-on afterthought. It includes compose override files (merge your own YAML at deploy time for port remapping or volume changes without touching the repo), per-service public port control with automatic subdomain assignment, and service-specific custom domain routing. Want api.example.com pointing at your API container and app.example.com at your frontend? Set the service_name on each custom domain.

Volumes survive redeployments (docker compose down runs without --volumes), and Temps injects its system environment variables into every compose service automatically. Full cleanup only happens when you delete the project or environment.

The UI got compose-specific touches too: a compose file picker that filters by root directory during project creation, per-service URLs in the container list, and screenshot capture for compose deployments.

Citation Capsule: Temps 0.0.7 introduces Docker Compose as a first-class deployment preset with service-specific custom domain routing, compose override files for deploy-time configuration, and automatic volume preservation across redeployments — making multi-container apps deployable via git-push alongside single-container presets.

How Does the Edge CDN Proxy Work?

The new temps edge CLI command launches a lightweight, stateless CDN proxy node powered by Pingora (Cloudflare's open-source proxy framework — see why we chose Rust). It doesn't need a database — just an origin URL and an edge token.

Here's what happens under the hood: the edge node registers with the control plane via a POST request, exchanging X25519 public keys. Every 15 seconds, it syncs its route table. Every 30 seconds, it sends a heartbeat with cache statistics.

The TLS certificate distribution uses ECIES encryption — X25519 ECDH key exchange with HKDF-SHA256 derivation and AES-256-GCM encryption. Each sync generates a fresh ephemeral keypair for forward secrecy. Certificates live in memory only; they're never written to disk on edge nodes.

The local cache is content-addressable with LRU eviction (triggered at 90% capacity, targets 80%, cycles every 60 seconds). You can label nodes by region with --region us-east for analytics grouping.

We also added SSRF protection for edge node address validation — loopback, link-local, metadata, and unspecified IPs are all blocked.

# Start an edge node
temps edge --origin https://control.example.com --token edge_xxx --region us-east

Configuration persists at ~/.temps/edge.json with 0600 permissions.

What Is Content-Addressable Storage?

Static assets are now stored using SHA-256 content hashing with git-style blob sharding (blobs/{prefix}/{hash}). If two deployments serve the same main.js file, Temps stores it once.

The static_asset_cache database table maps URLs to content hashes, so the proxy can resolve assets without touching the filesystem. When you deploy a new version, old assets stay accessible via the stale-chunk fallback until nightly garbage collection cleans up unreferenced blobs.

You can purge the cache manually through the API (DELETE /projects/{id}/asset-cache) or the new "Purge Asset Cache" button in environment settings.

The underlying FsFileStore was rewritten completely — it's now a proper content-addressable store where identical content shares a single blob regardless of which deployment or path references it.

Citation Capsule: Temps 0.0.7 introduces content-addressable static asset storage using SHA-256 hashing with git-style blob sharding, DB-backed URL-to-hash mapping for proxy-level resolution, and nightly garbage collection — deduplicating identical assets across deployments while keeping old chunks accessible until cleanup.

How Do Container Exec Terminals Work?

You can now exec into running containers directly from the Temps dashboard or API. There are two modes:

One-shot commands via POST /projects/{id}/environments/{env_id}/containers/{container_id}/exec — send a command, get the output back.

Persistent terminals via WebSocket upgrade — full xterm.js-compatible PTY sessions with resize support. Open a terminal tab in the dashboard and you're connected to a live shell inside your container.

Container exec is opt-in per project (set container_exec_enabled) and gated by the ContainersExec permission.

What Does Email Tracking Cover?

Email tracking in 0.0.7 has two components: open tracking and click tracking. This builds on the transactional email system shipped in earlier releases.

Open tracking injects a 1x1 transparent pixel before </body> in outgoing HTML emails when track_opens: true is set. The pixel hits a public endpoint that records the open event with IP and user-agent, then returns a GIF.

Click tracking rewrites all HTTP/HTTPS links in your email to route through Temps. The redirect endpoint records the click and 302-redirects to the original URL. Smart links like mailto:, tel:, #anchor, and javascript: are left untouched.

Both features are opt-in per email via the send API:

{
  "to": "user@example.com",
  "subject": "Welcome",
  "html": "<h1>Hello</h1>",
  "track_opens": true,
  "track_clicks": true
}

The tracking data is queryable through authenticated API endpoints — you can get a summary with unique open/click counts, filterable event lists, and per-link click stats. The Sent Emails table in the dashboard shows open and click counts with icons, and the Email Detail page has a tracking stats card.

This feature ships with 116 tests: 12 tracking service integration tests, 14 HTTP handler tests, and a full end-to-end flow test covering send, open, click, query, and database state verification.

Citation Capsule: Temps 0.0.7 adds email open and click tracking with transparent pixel injection and link rewriting, backed by 116 tests including a full E2E flow test — providing built-in email analytics without external services like Mailgun or SendGrid tracking add-ons.

What Are the New CLI Deploy Commands?

Three new commands let you deploy without going through the git-push workflow:

temps deploy image — Deploy a pre-built Docker image from any registry. Point it at ghcr.io/your-org/your-app:latest and Temps pulls and runs it.

temps deploy static — Deploy static file directories or archives (.tar.gz, .zip). If you pass a directory, Temps auto-creates a tar.gz for you.

temps deploy git — Trigger the build pipeline from a specific commit, branch, or tag without pushing code.

All three support --wait with configurable --timeout and 5-second polling. Authentication uses TEMPS_API_URL and TEMPS_API_TOKEN environment variables — drop these into your CI pipeline and you're set.

# Deploy a Docker image
temps deploy image --project my-app --image ghcr.io/org/app:v2.1.0 --wait

# Deploy static files
temps deploy static --project docs-site ./dist --wait

# Trigger a build from a specific tag
temps deploy git --project my-app --ref v2.1.0 --wait

Citation Capsule: Temps 0.0.7 adds three CLI deploy commands — temps deploy image, temps deploy static, and temps deploy git — each with --wait polling and environment variable authentication, enabling CI/CD pipelines to deploy pre-built images, static archives, or specific git refs without the git-push workflow.

What Else Shipped in 0.0.7?

Beyond the headline features, 0.0.7 includes a long tail of fixes and improvements:

Health Monitoring

• Monitors now accept 404/405 as healthy status codes — no more false alarms from APIs that return 404 on their root path. See how uptime monitoring works for the full architecture
• Custom health check paths via .temps.yaml configuration
• E2E deployment test workflow for CI validation

Public Repository Support

• URL input field in Git Settings for public repos with a "Public" badge
• Authenticated GitHub API calls (5,000 req/hr instead of 60 for anonymous)
• Branch listing pagination for repos with 100+ branches (GitHub and GitLab)

UI Improvements

• Infrastructure pages moved under Settings with sidebar navigation
• Command palette (Cmd+K) synced with actual routes
• Network throughput shows actual rate instead of cumulative totals
• Container name truncation fixed in monitoring
• Container selector text aligned left

Critical Bug Fixes

• Workflow context clobbering: Parallel jobs were overwriting each other's outputs. The executor now merges outputs — this was the root cause of containers not registering after deployment.
• Container registration silently skipped: persist_static_assets was blocking mark_deployment_complete. It now runs as non-blocking, best-effort.
• Orphaned container teardown: Added slug-based fallback cleanup for containers with no database records.
• SQL injection surface: ORDER BY identifiers are now quoted for CamelCase PostgreSQL column support; static asset cache DELETE is fully parameterized.

Under the Hood

• git2 (libgit2) replaces all Command::new("git") CLI calls — git is no longer a runtime dependency
• persist_static_assets runs in parallel with mark_deployment_complete instead of blocking it
• The standalone temps-compose crate was removed; compose lives as a deployment preset alongside everything else

How Do I Upgrade?

If you're on Temps Cloud, you're already on 0.0.7.

For self-hosted installations, pull the latest binary:

curl -fsSL https://get.temps.sh | bash

Or use the CLI:

temps update

Docker Compose deployments work immediately — create a new project, select the Docker Compose preset, and push your repo. The edge CDN requires launching a separate temps edge process on your CDN nodes. All deployments continue to use zero-downtime rolling updates.

If you're running a multi-node cluster, upgrade the control plane first, then worker nodes.

Check the full changelog for the complete list of changes.

Frequently Asked Questions

Does Docker Compose support work with existing projects?

Yes. Change your project's preset to Docker Compose in the project settings. Temps will detect your compose file on the next deployment and run the 3-stage DownloadRepo → DeployCompose → MarkComplete pipeline. You can also add a compose override to customize ports and volumes without modifying your repository.

Do edge CDN nodes require a database?

No. Edge nodes are stateless — they only need the origin URL and an edge token. Route tables sync every 15 seconds from the control plane, heartbeats report every 30 seconds, and TLS certificates are delivered via ECIES encryption and stored in memory only.

Is email tracking GDPR-compliant?

Open and click tracking are opt-in per email (both default to false). You control when tracking is enabled. The tracking data (IP, user-agent, timestamps) is stored in your own database — not a third-party service. The feature is backed by 116 tests including a full E2E flow.

Can I use the CLI deploy commands in CI/CD?

Yes. Set TEMPS_API_URL and TEMPS_API_TOKEN as environment variables in your CI pipeline. All three commands (image, static, git) support --wait with 5-second polling and configurable --timeout for blocking until the deployment completes.

Does container exec work with Docker Compose deployments?

Yes. You can exec into any individual service container within a compose deployment. Enable container_exec_enabled on the project and ensure the user has the ContainersExec permission.

Temps is a self-hosted PaaS that replaces Vercel, Plausible, Sentry, FullStory, and Pingdom with a single binary. Get started with Temps or check out the Temps vs Coolify vs Netlify comparison.