> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vulpy.io/llms.txt
> Use this file to discover all available pages before exploring further.

# DNS records for a Vulpy Commerce live shop

> The DNS records Vulpy Commerce expects for a live environment, plus wildcard, staging label, and preview-host patterns for the golive cutover.

Every Vulpy Commerce environment exposes four hostnames: the storefront, a preview host, the Medusa API, and Matomo analytics. Point each hostname to your VPS public IP with an A record (or AAAA for IPv6). If you use a load balancer, use a CNAME instead. Caddy handles TLS automatically once DNS resolves.

<Tip>
  **Ask Fox to draft the record set.** Fox knows your storefront and staging labels and can spit out the exact records for your registrar.

  Try prompts like:

  * "What DNS records do I need for shop.example.com?"
  * "Draft a Cloudflare record set for staging and live."
  * "Explain why wildcards are useful here."
</Tip>

## Live environment records

| Hostname                                           | Purpose                                 | Notes                                                                                         |
| -------------------------------------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------- |
| `SHOP_DOMAIN` (e.g. `shop.example.com`)            | Storefront and Payload admin (`/admin`) | Primary shop URL.                                                                             |
| `www.<SHOP_DOMAIN>`                                | Redirect                                | Caddy returns a 301 to the apex domain.                                                       |
| `PREVIEW_DOMAIN` (e.g. `preview.example.com`)      | Preview storefront                      | Served with `noindex` until golive. After golive, Caddy redirects it to the apex shop domain. |
| `API_DOMAIN` (e.g. `api.example.com`)              | Medusa API and admin (`/app`)           | Backend and admin dashboard.                                                                  |
| `MATOMO_DOMAIN` (defaults to `analytics.<domain>`) | Self-hosted Matomo                      | Production only. Consent-gated.                                                               |

Create one A record per hostname that points to the public IP of your server. If you prefer, a single wildcard A record `*.example.com` covers all four labels at once, and makes adding a staging environment later effortless.

## Staging environment

Staging uses the same four hostnames, but prefixed with `staging.` on your domain. For example:

* `staging.shop.example.com`
* `staging.preview.example.com`
* `staging.api.example.com`
* `staging.analytics.example.com`

Create the same A or CNAME records for the staging labels, pointing to the staging server IP. Because environments are isolated Docker Compose projects, staging and live can run on the same host or on separate hosts.

## Tailscale-only installs

If you chose Tailscale as your access mode during installation, no public DNS records are required. Fox and all services are reachable inside your tailnet via Tailscale MagicDNS names. The Fox WebUI and storefront are served over HTTPS on ports 443 and 80 directly on the MagicDNS hostname. For details, see [Tailscale access](/fox/tailscale).

## No-domain mode (sslip.io)

When you select no public domain during setup, DNS is implicit. Each hostname resolves automatically through sslip.io using your server IP, for example `203.0.113.4.sslip.io`. This is useful for quick previews, demos, and test installs without registering a domain. You can switch to a real domain later by updating the environment configuration and creating the records below.

## Wildcard records

A single wildcard record `*.example.com` pointing to your server IP covers the apex shop, preview, API, analytics, and any future staging labels. This is the recommended pattern unless your DNS provider does not support wildcards.

## Change your domain

<Steps>
  <Step title="Set the new domain">
    Run the CLI command for the target environment:

    ```bash theme={null}
    pnpm vulpy env set-domain live --domain example.com
    ```
  </Step>

  <Step title="Verify the environment">
    Confirm the variables updated correctly:

    ```bash theme={null}
    pnpm vulpy env status live
    ```
  </Step>

  <Step title="Point DNS">
    Create or update the A records for the four hostnames to the server IP.
  </Step>

  <Step title="Go live">
    Once DNS resolves, run:

    ```bash theme={null}
    pnpm vulpy env golive live
    ```
  </Step>
</Steps>

<Warning>
  Point your DNS records to the server IP **before** running `pnpm vulpy env golive live`. Caddy requests a TLS certificate from Let's Encrypt or ZeroSSL immediately. If DNS has not propagated, ACME will fail and enter retry backoff, which delays serving HTTPS.
</Warning>

<CardGroup cols={2}>
  <Card title="Go live" icon="rocket" href="/deploy/going-live">
    Run the golive command, verify HTTPS, and switch the preview host to production.
  </Card>

  <Card title="Edge deploy" icon="globe" href="/deploy/edge">
    Deploy to edge nodes, manage edge environment status, and view edge logs.
  </Card>
</CardGroup>