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

Temps 0.0.7 ships six major features in a single self-hosted binary: Docker Compose as a first-class deployment preset, a Pingora-powered Edge CDN proxy, content-addressable static asset storage, WebSocket container exec terminals, email open/click tracking with 116 tests, and three new CLI deploy commands. All of these are available free to self-host (Apache 2.0) or on Temps Cloud for ~$6/mo — no per-seat fees, no bandwidth bills.

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

TL;DR: Temps 0.0.7 adds Docker Compose as a deployment preset with multi-service domain routing and compose override files, a stateless Pingora-powered Edge CDN with ECIES-encrypted TLS distribution and LRU content cache, content-addressable static asset storage with SHA-256 deduplication, WebSocket PTY container exec terminals, email open/click tracking with 116 tests including a full E2E flow, and three new CLI deploy commands (image, static, git) with --wait and CI-friendly env auth.

What's New in Temps v0.0.7?

What Changed in Docker Compose Deployments?

Docker Compose is a first-class deployment preset 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 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 via an auto-generated docker-compose.temps-env.yml override. 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 a DownloadRepo → DeployCompose → MarkComplete pipeline, service-specific custom domain routing via a service_name column on project_custom_domains, compose override files for deploy-time configuration merging, 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 bunx @temps-sdk/cli edge 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 self-registers with the control plane via POST /api/internal/nodes/register, exchanging X25519 public keys. Every 15 seconds it syncs its route table from GET /api/internal/edge/routes. Every 30 seconds it sends a heartbeat with cache statistics (hit rate, disk usage, entry count).

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. SSRF protection blocks loopback, link-local, metadata, and unspecified IPs from edge node address registration.

# Start an edge node (no database required)
bunx @temps-sdk/cli edge --origin https://control.example.com --token edge_xxx --region us-east

Configuration persists at ~/.temps/edge.json with 0600 permissions. Node ID and private key are generated once and stored there.

Citation Capsule: The Temps Edge CDN proxy is a stateless Pingora-powered node that self-registers via X25519 key exchange, syncs routes every 15 seconds, delivers TLS certificates via ECIES (X25519 ECDH + HKDF-SHA256 + AES-256-GCM) with per-sync ephemeral keypairs for forward secrecy, caches assets with LRU eviction (90% trigger / 80% target), and reports heartbeats every 30 seconds — all without requiring a database.

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 and maps both URLs to the same blob.

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 "Purge Asset Cache" button in environment settings.

Citation Capsule: Temps 0.0.7 stores static assets as content-addressable blobs using SHA-256 hashing with git-style sharding (blobs/{prefix}/{hash}), backed by a static_asset_cache DB table for URL→hash mapping at the proxy layer, a stale-chunk fallback that keeps old deployment assets accessible, and nightly GC for unreferenced blobs — deduplicating identical assets across deployments without breaking live traffic.

How Do Container Exec Terminals Work?

You can 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 synchronously.

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 (container_exec_enabled) and gated by the ContainersExec permission. This works with Docker Compose deployments too — you can exec into any individual service container within a compose deployment.

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 GET /api/emails/{id}/track/open, which 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 GET /api/emails/{id}/track/click/{link_index} when track_clicks: true is set. The redirect endpoint records the click event 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 (both default to false):

{
  "to": "[email protected]",
  "subject": "Welcome",
  "html": "<h1>Hello</h1>",
  "track_opens": true,
  "track_clicks": true
}

Tracking data is queryable through authenticated API endpoints — GET /api/emails/{id}/tracking returns a summary with unique open/click counts; GET /api/emails/{id}/tracking/events is filterable by event type; GET /api/emails/{id}/tracking/links returns 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 showing first-event timestamps.

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 pixel → click redirect → query tracking summary → database state verification.

Citation Capsule: Temps 0.0.7 email tracking uses pixel injection (GET /api/emails/{id}/track/open) and per-link rewriting (GET /api/emails/{id}/track/click/{link_index}) — both opt-in per email, data stored in your own DB across email_events and email_links tables, with authenticated analytics endpoints. 116 tests including a full E2E flow ship with the feature.

What Are the New CLI Deploy Commands?

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

bunx @temps-sdk/cli 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.

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

bunx @temps-sdk/cli 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 from any registry
bunx @temps-sdk/cli deploy image --project my-app --image ghcr.io/org/app:v2.1.0 --wait

# Deploy static files or a directory (auto-creates tar.gz)
bunx @temps-sdk/cli deploy static --project docs-site ./dist --wait

# Trigger a build from a specific git tag
bunx @temps-sdk/cli deploy git --project my-app --ref v2.1.0 --wait

Citation Capsule: Temps 0.0.7 adds three CLI deploy commands — deploy image, deploy static, and deploy git — each with --wait and 5-second polling, authenticated via TEMPS_API_URL + TEMPS_API_TOKEN environment variables for CI/CD pipelines that need to deploy pre-built images, static archives, or specific git refs outside the git-push workflow.

What Else Shipped in 0.0.7?

Beyond the headline features, 0.0.7 includes fixes and improvements across health monitoring, public repository support, the UI, and the deployment engine.

Health Monitoring

• Monitors now accept 404/405 as healthy status codes — no more false alarms from APIs that return 404 on their root path
• 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

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 Dockerfile, static, and other presets

How Does Temps Compare to Alternatives for These Features?

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:

bunx @temps-sdk/cli 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 bunx @temps-sdk/cli 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 detects your compose file on the next deployment and runs the DownloadRepo → DeployCompose → MarkComplete pipeline. You can also add a compose override file 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. A node can be added or removed without touching the control plane database.

Is email tracking GDPR-compliant?

Open and click tracking are both 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. This works with any CI system — GitHub Actions, GitLab CI, CircleCI, or any pipeline that can run bunx @temps-sdk/cli.

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.

Is content-addressable storage automatic?

Yes. All static asset deployments automatically use SHA-256 content hashing. Identical files across different deployments share a single blob. You don't need to configure anything — the FsFileStore handles deduplication transparently. You can manually purge the asset cache via DELETE /projects/{id}/asset-cache or the dashboard UI.

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.