Add post on auto-TLS verification step and improve 404 style

[alexellis]

Add post on auto-TLS verification step and improve 404 style

Auto TLS will now verify the CA before trusting it using the token itself to HMAC a nonce the client presents.

404 page restyled

Before/After

[reviewfn]

AI Pull Request Overview

Disclaimer: This review was generated by automated AI and may contain errors. Do not trust its outputs without human verification.

Summary

• Adds a release/security blog post for inlets-pro 0.11.14 auto-TLS verification.
• Restyles the 404 page using a new minimal Jekyll layout.
• Updates footer navigation labels and ordering for mobile and desktop.
• Adds only whitespace to css/site.css.
• Main merge risk is the upgrade guidance in the new post, not the presentation changes.

Approval rating (1-10)

7/10. The site changes are low risk, but the security-release post needs clearer version-pinning guidance before publication.

Summary per file

Summary per file

File path	Summary
404.md	Replaces default 404 copy/image with a styled minimal 404 landing page.
_includes/footer.html	Reorders and relabels footer navigation links on mobile and desktop.
_layouts/minimal.html	Adds a lightweight layout for logo, content, and trademark footer.
blog/_posts/2026-07-13-hardening-auto-tls.md	Adds a security-release post explaining auto-TLS CA verification and upgrade paths.
css/site.css	Adds a blank line before Tailwind utilities.

Overall Assessment

The frontend changes are straightforward and consistent with the existing Tailwind-based site. The new post is useful and generally clear, but its primary upgrade path can leave readers thinking they have upgraded to inlets-pro 0.11.14 without the command actually pinning or verifying that server version. Because the post is about a security hardening release, that ambiguity should be fixed before publishing.

Detailed Review

Detailed Review

Findings

Medium: The inletsctl create upgrade path does not pin or verify inlets-pro 0.11.14

blog/_posts/2026-07-13-hardening-auto-tls.md:64-70

The recommended upgrade path tells readers to run:

inletsctl delete
inletsctl create

It then says this gives them “a fresh server running 0.11.14.” The command shown does not include a version flag or a verification step, and existing repository guidance uses an explicit --inlets-pro-version flag when the installed server version matters. If a reader has an older inletsctl, a cached/default server version, or provider automation that has not been updated yet, they may recreate the tunnel and still not get the hardened auto-TLS behavior described by the post.

Make the security-critical path explicit. For example, show the version flag in the recreated command, or add a concrete instruction to update inletsctl and verify the resulting server/client version before assuming the migration is complete:

inletsctl create \
  --inlets-pro-version 0.11.14

Include the reader's existing provider, region, token, and domain flags in the example or immediately below it, so the command remains reproducible rather than illustrative only.

Content review

No blocking findings beyond the version-pinning issue above.

The title and description fit the article: they frame this as a hardening release and set the expected security context. The opening is accessible for users familiar with SSH trust-on-first-use and quickly explains why auto-TLS changed.

The structure is readable: threat model, mechanism, affected products, upgrade path, compatibility bridge, token requirements, and links. That sequence works for a release post where readers need to decide whether and how to upgrade.

The examples are concise, but the destructive recreate path needs stronger guardrails because it tells users to delete infrastructure. The DNS TTL note helps, but the version ambiguity above is important enough to fix before publication.

The 404 and footer changes do not introduce an obvious correctness issue in the scoped diff. The new minimal layout is narrow in purpose and avoids changing the default layout used by the rest of the site.

AI agent details.

Agent processing time: 1m50.351s
Environment preparation time: 3.476s
Total time from webhook: 1m58.928s

[alexellis]

Release landed: https://github.com/inlets/inlets-pro/releases/tag/0.11.14