ACCID SSL / Subdomain Architecture Note

Core Doctrine

ACCID is the builder, not the production site. The current environment is an authoring framework where users create, preview, edit, and iterate safely; publishing produces a separate deployable artifact such as static HTML, React, Astro, or Next.js.[cite:1]

This distinction keeps the system focused. The internal workspace can optimize for editing, safety, routing flexibility, and fast iteration, while the published output can optimize for portability, performance, and deployment fit.[cite:1]

Three Tiers

Identity Model

The stable concept across all tiers is the project slug. A user can build a project under one internal name, publish that same name to accid.cloud, and later export or host it elsewhere without changing the project’s identity model.[cite:1]

That means the name is the invariant, while the mount point changes. The builder stays the source system; publish and export are delivery modes.[cite:1]

User Flow

flowchart TD
    A[User creates project in ACCID builder] --> B[Project lives in safe zone]
    B --> C[Preview and iterate inside builder]
    C --> D{What does the user want next?}
    D --> E[Publish to ACCID-managed domain]
    D --> F[Export to external target]
    E --> G[project.accid.cloud]
    E --> H[Managed wildcard DNS + TLS + routing]
    F --> I[Static HTML export]
    F --> J[Framework export: React / Astro / Next.js]
    F --> K[Deploy to user VPS or host]
    G --> L[Public live site]
    I --> L
    J --> L
    K --> L

Builder Versus Front End

Even when users are looking at the “front end” inside ACCID, they are still in the builder context. They are viewing a render or preview inside a controlled authoring system, not interacting with the final contractual production surface.[cite:1]

This is important because it prevents internal preview behavior from becoming accidental product debt. Draft routes, editing overlays, debug helpers, and safe-zone assumptions remain valid inside the builder precisely because the builder is not the shipped artifact.[cite:1]

Publishing Model

Publishing should be treated as a transformation step, not as a mode switch where the builder suddenly becomes production. The builder remains the source of truth, and publishing emits a deployable result to a chosen target domain or framework shape.[cite:1]

This allows ACCID to support multiple output forms without losing architectural clarity. Static HTML, React, Astro, Next.js, and other targets are all publish formats, not separate products.[cite:1]

Current Wildcard Setup Record

The wildcard pattern works because DNS, TLS, and name-based routing are separated cleanly. The DNS zone proves domain control through a TXT record, the wildcard certificate terminates TLS on the front door, and nginx forwards requests by hostname to the appropriate upstream.[cite:1]

The current setup on shawns-machine.com uses wildcard DNS plus a manually issued DNS-01 wildcard certificate. Once the certificate is installed, nginx can serve HTTPS for arbitrary subdomains without creating a new certificate or nginx config for each one.[cite:1]

FreeDNS / afraid.org Steps

These are the recorded steps for issuing the wildcard certificate through FreeDNS / afraid.org using Certbot DNS-01 validation.[cite:1]

1. On the front-door server, run:

sudo certbot certonly --manual --preferred-challenges dns -d '*.shawns-machine.com'

Certbot pauses and prints a one-time token. It asks for a TXT record under _acme-challenge.shawns-machine.com with the token value.[cite:1]

2. In FreeDNS / afraid.org, create or edit the TXT record with these values:[cite:1]

3. Save the TXT record in FreeDNS. The important detail is that the token goes in the Destination field, not an IP address, and the quotes belong around the TXT value, not around the subdomain field.[cite:1]
4. Before returning to Certbot, verify propagation from another terminal:

dig +short TXT _acme-challenge.shawns-machine.com

When the returned TXT value matches the Certbot token, go back to the waiting Certbot session and press Enter to continue.[cite:1]

5. On success, Certbot stores the wildcard certificate under the shawns-machine.com live directory rather than a literal asterisk path, for example:

/etc/letsencrypt/live/shawns-machine.com/fullchain.pem
/etc/letsencrypt/live/shawns-machine.com/privkey.pem

That certificate is then available to the wildcard nginx server block.[cite:1]

FreeDNS Notes

The _acme-challenge label is expected and standard for Lets Encrypt DNS validation. The TXT record is effectively a receipt for a completed proof of domain control, and the token itself has no long-term value after validation completes.[cite:1]

The TXT record can be left in place for convenience or updated at renewal time, but each new validation run uses a fresh token. This means the renewal ritual repeats the same shape even though the value changes.[cite:1]

Wildcard DNS Record

The DNS zone also contains a wildcard A record for *.shawns-machine.com pointing at 136.24.209.105, which allows previously unseen subdomains to resolve to the front-door server automatically.[cite:1]

That wildcard A record is what makes arbitrary subdomain routing possible once the wildcard TLS certificate and wildcard nginx config are in place.[cite:1]

nginx Wildcard Catch-All

The wildcard nginx block that completed the setup was recorded in this shape:[cite:1]

server {
    server_name *.shawns-machine.com;

    client_max_body_size 50M;
    proxy_request_buffering off;
    proxy_read_timeout 120s;
    proxy_send_timeout 120s;

    location / {
        proxy_pass http://192.168.1.9:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/shawns-machine.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/shawns-machine.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

server {
    listen 80;
    server_name *.shawns-machine.com;
    return 301 https://$host$request_uri;
}

This block terminates TLS on the wildcard certificate and forwards the original hostname to the upstream. The forwarded Host header is the key piece, because it lets the upstream vhost decide which tenant or project folder should answer the request.[cite:1]

Operational Steps After Config

After placing the wildcard config file in nginx, the operational sequence is:[cite:1]

1. Test the config:

sudo nginx -t

2. Reload nginx:

sudo systemctl reload nginx

3. Test a never-before-used subdomain:

curl -sI https://zz-wildcard-era-begins.shawns-machine.com | head -3

An HTTP response over TLS, even if it is a 404 because no backing folder exists yet, proves the wildcard certificate and catch-all routing are functioning.[cite:1]

What the 404 Meant

The recorded HTTP/2 404 result on a never-before-seen subdomain was not a failure. It proved that DNS resolved, the wildcard certificate was served correctly, nginx accepted the hostname, and the request reached the wildcard path; the only missing piece was content behind that name.[cite:1]

That is the exact desired state for an “infinite subdomain” builder. A new folder, symlink, or tenant mapping can make a new subdomain live without any additional certificate or nginx work.[cite:1]

Product Implications

This model gives ACCID a clear ladder:

• Build in a safe internal environment.
• Publish to an ACCID-managed public domain.
• Export to user-owned infrastructure when needed.[cite:1]

That separation also creates a natural business boundary. Building can remain easy and protected, while publishing becomes the moment where users receive public hosting value and where product gating or paid tiers make more sense.[cite:1]

Operating Principle

A concise architecture sentence for the project is:

ACCID is the authoring environment; published sites are output artifacts. Users build and preview in a controlled workspace, then publish to managed domains or export to external runtimes without changing the project’s identity.[cite:1]