# Add Custom Domain

Add a custom domain to a Temps project and provision an automatic SSL/TLS certificate...

- Repository: https://github.com/gotempsh/temps (887 stars)
- Category: DevOps
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add gotempsh/temps --skill add-custom-domain -g -a claude-code -y`
Codex: `npx skills add gotempsh/temps --skill add-custom-domain -g -a codex -y`
Cursor: `npx skills add gotempsh/temps --skill add-custom-domain -g -a cursor -y`
Gemini CLI: `npx skills add gotempsh/temps --skill add-custom-domain -g -a gemini-cli -y`

## Description

Add a custom domain to a Temps project and provision an automatic SSL/TLS certificate via Let's Encrypt, driven entirely from the `@temps-sdk/cli` CLI. Handles subdomains, apex domains, HTTP-01 and DNS-01 challenges, wildcard domains, and domains served through a Cloudflare Tunnel (no certificate, no open ports). Use when the user wants to: (1) Add a custom domain to their Temps app, (2) Set up HTTPS/SSL for a deployment, (3) Point their own domain at a Temps project, (4) Add a wildcard domain, (5) Configure DNS for Temps, (6) Expose an app on a worker behind NAT through a tunnel. Triggers: "add custom domain", "point my domain at temps", "set up ssl", "https for my app", "wildcard domain", "add domain to project", "cloudflare tunnel", "expose app without open ports".

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Add a Custom Domain

Add a custom domain to a Temps project and get automatic HTTPS. This skill drives
the whole flow from the CLI; the human equivalent is **Project → Domains → Add Domain**
in the dashboard.

## When to use

The user wants their own domain (e.g. `app.example.com`) serving a Temps project,
with an SSL certificate, instead of the auto-assigned subdomain.

## Prerequisites

- The Temps CLI is authenticated. Verify, and log in to the user's instance if needed
  (`login` is a top-level command; the instance URL is the positional argument):
  ```bash
  bunx @temps-sdk/cli whoami || bunx @temps-sdk/cli login "<instance_url>"
  ```
- The user knows the **domain** to add and which **project** it belongs to.
- The user can edit DNS for the domain (or has a DNS provider connected in Temps
  for DNS-01 / wildcard).

## First: does a tunnel already cover the domain?

If the apps run on workers with an ingress tunnel (ADR 058), the domain needs
**no DNS record and no certificate**: Temps creates the record and the tunnel's
provider serves HTTPS. Check before anything else:

```bash
bunx @temps-sdk/cli tunnels list --json
bunx @temps-sdk/cli tunnels explain app.example.com --json
```

If `explain` lists a tunnel in `candidates` (its `domain` is `example.com` or a
parent of the name):

1. Attach the name to the environment (step 3 below, same command). Do **not**
   create a certificate for it: tunnel traffic reaches Temps as plain HTTP, and
   a local certificate makes the proxy redirect it to HTTPS.
2. If the tunnel publishes only chosen names, or several tunnels cover it,
   route it explicitly:
   ```bash
   bunx @temps-sdk/cli tunnels route app.example.com --tunnel <tunnel-id>
   ```
3. Within a minute `tunnels explain app.example.com` should report `published`.
   Its `detail` says what to fix when it does not (the usual one: no deployed
   app on a worker serves the name yet).

The rest: https://github.com/gotempsh/temps/blob/HEAD/skills/add-custom-domain/SKILL.md