Built and verified. This work is live and was checked against its plan.

tenctrl.fr Public Site

tenctrl.fr serves a static French product page over HTTPS from nginx, with no script, no cookie and no third-party resource, outside the TenCtrl application runtime.

Overview

TenCtrl needed a public page that explains the product honestly while the application itself stays private. The page was designed on a Claude Design canvas, written as plain HTML and CSS, and published on the same VPS as a separate nginx site.

Problem

The product is in development. A public page had to describe it without overstating what exists, comply with French legal-notice requirements, and add no attack surface to the application that holds Microsoft sessions.

Constraints

  • Describe only built capabilities, or label them as planned.
  • No route from the public domain to the application runtime.
  • A strict Content-Security-Policy: everything from the site's own origin, fonts self-hosted.
  • Do not disturb the other sites served by the same nginx.

Approach

Keep the site to static files in its own repository, guard them with tests, deploy releases behind an atomic symlink switch, then add TLS once the DNS points to the host.

Key decisions

Serve the page from nginx, outside the Next.js application.

A public apex host with no path to the application keeps the private development runtime unexposed, and application restarts cannot take the page down.

Alternatives considered

  • A route group inside the Next.js application, proxied on the apex host.

Guard tests on the static files.

Node's built-in test runner fails the deploy on any external reference, inline script or style, broken link, or missing legal and disclaimer text, so the strict CSP stays true as the page changes.

Alternatives considered

  • Manual review before each deploy.

Result

Third-party requests
0
Cookies
0
Guard tests
15

https://tenctrl.fr answers with a valid certificate; HTTP and www redirect to it; HSTS and a default-src 'self' policy are sent; the existing sites on the host were checked unchanged after each nginx reload.

Learnings

  • Applying the product's evidence rule to marketing copy produces a clear 'built / planned / out of scope' page instead of feature claims.
  • Testing the static files for external references is what keeps a strict CSP from breaking silently later.

Delivery steps

  1. Design on a canvas, then port to plain HTML and CSS.
  2. Guard tests and desktop and phone render checks in headless Chromium.
  3. Release directory plus symlink switch, so rollback is one link.
  4. nginx vhost validated with nginx -t before each reload.
  5. Certificate issued by webroot challenge once the DNS pointed to the host, with a renewal hook that reloads nginx.

Editorial And Release Method

The public page uses the same evidence discipline as the product:

  1. Start from the repository, not a feature wish list. The copy is checked against the current TenCtrl implementation and its documented capability states before it is published.
  2. Separate present, planned and excluded work. The page has dedicated sections for what is available in the development environment, what belongs to V1 and what TenCtrl will not do. A capability is not promoted from one section to another because a design or route exists.
  3. Keep the public surface independent. The page is static, has no application session, cookie, analytics script or third-party request, and is served from a separate nginx vhost rather than from the private product runtime.
  4. Make the contract executable. Repository tests reject external resources, inline code, broken links and missing legal or trademark statements. The deploy script runs those tests before publishing.
  5. Publish a reversible release. Static output is prepared as a release, the existing webroot is retained as a backup and the public HTTPS endpoint is checked after deployment. This makes rollback a defined operation rather than an emergency edit.
All projects