Pyro Studios × LeoLabs
How It Works Under the Hood
A technical deep dive into the infrastructure, capabilities, and long-term architecture of the rebuilt LeoLabs website.
SCROLL TO EXPLORE ↓
01 - Architecture
The Big Picture
The new architecture completely separates the public website from content management. The public site is static files on a global CDN. No server, no database, nothing to hack.
Public Website Path
Visitors
Global traffic
Cloudflare CDN
300+ edge locations
Static Site
HTML / CSS / JS
Content Management Path
Victoria / Team
Content editors
Custom Admin Panel
Private admin panel
Build Pipeline
Auto-rebuild
Cloudflare Pages
Deploy to CDN
02 - Framework
Why SvelteKit
The framework choice is genuinely forced by the security posture, not picked for taste. Pyro evaluated nine candidates and verified dependency counts directly. SvelteKit is the only candidate with a meaningfully smaller supply-chain footprint, and the only one with a first-party Cloudflare adapter for the all-Cloudflare stack.
SvelteKit ships ~98 transitive packages in a realistic project setup, versus ~279 for Next.js and ~420 for Astro with comparable integrations. Fewer packages means fewer entry points for supply-chain attacks.
The official @sveltejs/adapter-cloudflare provides native bindings for D1, R2, KV, and Workers. No translation layer, no community-maintained adapter, no surprise feature gaps.
Components compile to vanilla JavaScript with no virtual DOM runtime. Pages typically ship 2 to 4 times less JavaScript than equivalent React-based sites.
One data-loading paradigm, one component model. A maintainer ramps faster on a SvelteKit codebase than on Next.js, where multiple overlapping rendering paradigms (server vs client components, server actions, route handlers, SSR vs SSG vs ISR) coexist.
SvelteKit is used in production by The New York Times, Apple, and IBM among others. Stable API, stable adapter ecosystem.
Framework Comparison
A side-by-side look at the candidates evaluated, with verified dependency counts.
Dependency counts measured from clean installs with TypeScript and standard integrations on April 23, 2026.
03 - Infrastructure
Cloudflare: Our Foundation
LeoLabs already uses Cloudflare for DNS. We are expanding into their full ecosystem: hosting, storage, video, and security, all under one roof with one dashboard.
Cloudflare Pages
Static site hosting with a global CDN. Every deploy is automatically distributed to 300+ edge locations worldwide. Instant cache invalidation. Automatic SSL. Zero server management.
- →Automatic deploys from Git pushes
- →Free tier covers virtually all traffic
- →Preview URLs for every branch
- →One-click rollback to any deploy
Cloudflare D1
SQLite-based database running at the Cloudflare edge. The CMS database lives here. No network-exposed connection string, no separate vendor, accessed only through Workers bindings.
- →No public network endpoint to attack
- →Bound to specific Workers with least privilege
- →Automatic point-in-time backups
- →Same-vendor security boundary as the rest of the stack
Cloudflare R2
Object storage for all site images, documents, and media files. S3-compatible API but with zero egress fees. No bandwidth surprises, ever.
- →No egress fees (AWS S3 charges per download)
- →S3-compatible: works with existing tools
- →Served via Cloudflare's CDN automatically
- →Generous free tier for most use cases
Cloudflare Stream
Video hosting with adaptive bitrate streaming. Upload once, Cloudflare handles encoding, CDN delivery, and player. Custom player skins with CSS.
- →Adaptive bitrate: auto quality adjustment
- →Custom player API for branded video skins
- →Videos served from CDN, not your server
- →No bandwidth overages: flat per-minute pricing
Cloudflare Workers
Edge functions for the small bits of dynamic logic the site needs: contact form processing, admin API, scheduled integrations. Each Worker runs in isolation with explicit, scoped bindings to D1, R2, and external secrets.
- →Isolated runtime per request
- →Bindings to D1 and R2 for least-privilege access
- →Scheduled triggers for Greenhouse and LinkedIn jobs
- →MailChannels integration for transactional email
Cloudflare WAF + Turnstile
Web Application Firewall, DDoS mitigation, bot management, IP allowlisting on the admin panel, and Turnstile in place of Google reCAPTCHA on every form. Defense at the edge before requests reach the application.
- →IP allowlist on admin enforced at the edge
- →Country-level blocking, rate limiting, bot management
- →Cloudflare Managed Rules + OWASP Core Ruleset
- →Turnstile replaces Google reCAPTCHA: no tracking
Cloudflare DNS
Already in place at LeoLabs. The marketing site keeps using the existing DNS configuration. No migration, no zone transfer, no risk to any other LeoLabs services that already resolve through this DNS.
- ✓Already active — no migration needed
- →DNSSEC supported
- →Geo-routing and load balancing available if ever needed
Automated Security
What Cloudflare Handles For You
These features are active on every request, managed by Cloudflare's security team, and require zero maintenance from your side.
Managed rulesets updated continuously by Cloudflare's threat research team. OWASP Core Ruleset included. Not your problem to maintain.
Unmetered and always-on. Cloudflare has mitigated attacks exceeding 71 Tbps. Your site does not even notice.
Automated traffic filtering across their entire network. Scrapers, vulnerability scanners, and credential stuffers are blocked before they reach your content.
Block entire countries from accessing your site. China, Russia, Iran, North Korea. One toggle in the dashboard.
The admin panel is reachable only from LeoLabs-approved IP ranges. Enforced at the Cloudflare edge before requests reach the application. Anything else returns a 403.
Per-IP and global limits on the contact form, admin login, and any expensive endpoint. Configured at the edge.
Hand-authored CSP Level 3 with no unsafe-inline and no unsafe-eval. Inline scripts are eliminated where possible; remaining ones use SHA-256 hashes pinned in the policy.
frame-ancestors 'none' plus X-Frame-Options DENY. The site cannot be embedded inside a phishing page or competitor's iframe.
Full strict mode. HSTS with preloading. No mixed content. Every connection encrypted with TLS 1.3.
Replaces Google reCAPTCHA on every form. No visitor tracking, no Google data flow, free, fully within the Cloudflare boundary.
Cloudflare pushes WAF rule updates within hours of new CVEs being disclosed. You do not have to patch anything. They do it for you.
Cloudflare protects roughly 20% of all websites on the internet. They observe attack patterns across millions of sites and update defenses in real time. Your site benefits from the collective threat data of their entire network.
04 - Content Management
Custom Admin Panel + Cloudflare D1
A lightweight admin panel built on SvelteKit, backed by a Cloudflare D1 database that lives entirely inside the Cloudflare boundary. No external database vendor, no public network endpoint, no plugin ecosystem to keep patched.
Day-to-day usage of the admin panel (publishing, scheduling, change requests, LinkedIn approval queue) is documented on the Workflows page. This section focuses on the technology that runs underneath.
Built On
- →SvelteKit application running on Cloudflare Pages
- →Cloudflare D1 database, accessed only through Workers bindings (no network endpoint)
- →Tiptap rich text editor (headless, fully customizable)
- →Cloudflare R2 for image and document storage
- →Cloudflare Stream for video upload, encoding, and delivery
- →Microsoft Entra SSO via OIDC (no local passwords)
Content Types
Each content type has its own structured form with exactly the fields it needs. Greenhouse jobs and LinkedIn posts arrive automatically through scheduled, audited pipelines. Nothing free-form, nothing plugin-based.
Preview Before Publish
Every content edit can be previewed before going live. There is no “staging server” in the WordPress sense (a separate environment that has to be kept in sync). The new architecture handles preview through two complementary mechanisms:
- →Content preview rendered from the admin: while editing, click Preview to see exactly how the post or page will look on the live site. The render uses the same code path as the live site, against the in-progress draft.
- →Branch preview deployments for structural changes: Cloudflare Pages automatically generates a unique preview URL for every Git branch. New page designs, layout changes, and any work that goes through the change-request system land on a preview URL first. LeoLabs reviews and approves on the preview URL, then the change merges to main and goes live.
The result: every content change is previewable to the editor, and every code change is previewable to LeoLabs before going live. No long-running staging environment to maintain.
05 - Integrations
How External Systems Connect
Greenhouse jobs, LinkedIn posts, the platform visualization, and contact form submissions each go through a deliberate pipeline. None of them produce live runtime calls from the public site to a third party.
Greenhouse
Webhook-triggered, with optional admin queueWhen a job is posted, edited, or closed in Greenhouse, a webhook fires the build pipeline. There are two architectural options for what happens next, and the right answer depends on LeoLabs' preference.
- →Direct: webhook → GitHub Actions → site rebuilds with the latest jobs. Fully automated. New jobs appear within minutes with no manual step.
- →Reviewed: webhook → admin queue → an authorized user approves before the job goes live. Adds a human gate at the cost of a few minutes' delay.
Why this is secure: Either way, the Greenhouse API key lives in server-side secrets and never reaches the browser. By the time a visitor sees the careers page, it is static HTML.
Goal: write each post once on LinkedIn, have it appear on the website without re-entering it. A scheduled Worker fetches new posts twice a day; a Pull Now button in the admin triggers the same fetch on demand for timely posts. Two architectural options:
- →Direct: scheduled fetch → site rebuilds. Fully automated, no human step. Faster but with no review gate.
- →Reviewed: scheduled fetch → admin approval queue → authorized user approves. Recommended for LinkedIn given the higher security profile of social content.
Why this is secure: Either way, images are copied to LeoLabs' R2 bucket, so the live site never hotlinks LinkedIn's CDN. The reviewed option additionally guarantees nothing reaches the live site without an authorized human approving it.
Platform visualization
Integrate the existing visualization (architecture: discovery item)The plan is to integrate LeoLabs' existing platform visualization into the marketing site. The platform team has already built it; rebuilding it from scratch is not in scope. The architectural question is how to expose it on a public marketing site without making authenticated platform calls from the browser.
- →Snapshot pipeline (Daniel's suggested approach): the platform team publishes the visualization data to a bucket on a schedule; the marketing site fetches the snapshot at build time and renders it in 3D. No authenticated calls from the live site.
- →Decoupled public endpoint: the platform team exposes a hardened, unauthenticated read-only endpoint for visualization data. Lower implementation cost, slightly more runtime exposure.
Why this is secure: Whichever option is chosen, no authenticated calls are made from the live site. The visualization renders from a read-only, pre-computed data source. A compromise of the marketing site cannot reach live platform data. The specific architecture is finalized in discovery week with the LeoLabs platform team.
Contact form
Cloudflare Worker + MailChannelsThe form posts to a dedicated Worker. The Worker validates a Turnstile challenge, sanitizes input, and emails the submission to a configured LeoLabs inbox via MailChannels. By default no submissions are stored anywhere.
Why this is secure: If LeoLabs wants an archive, submissions are stored in a separate, isolated D1 database that has no shared code path with the CMS database. Different Worker, different binding, different blast radius.
Analytics
Cloudflare Web AnalyticsA lightweight beacon counts pageviews, unique visitors, top pages, referrers, and countries. No cookies, no consent banner required, free, included with Cloudflare. See Section 06 below for the in-depth privacy and consent reasoning.
Why this is secure: No personally identifiable information is collected. No third-party domain receives visitor data.
06 - Privacy & Consent
Cookies, GDPR, ePrivacy, and CCPA
Cookie consent is one of the most misunderstood parts of building a modern marketing site. The question isn't which vendor you use. It's what you collect and what you store.
The new site is engineered to avoid every category of tracking that triggers a consent banner under GDPR, ePrivacy, or CCPA. The Real Cookie Banner WordPress plugin is replaced by the absence of the underlying cookies.
The Rule
When is a consent banner legally required?
GDPR (and the ePrivacy directive, which is what actually governs cookies and trackers in the EU) requires prior, informed consent when a website does any of the following:
Storing information on the visitor's device
Cookies, localStorage, sessionStorage, or any other client-side storage used for tracking, analytics, or non-essential personalization. The act of writing to the device is what counts.
Accessing information already on the device
Reading existing cookies, fingerprinting browser characteristics, or pulling identifiers from the visitor's browser environment. This includes most fingerprinting techniques even when they don't write anything new.
Collecting personal data beyond what's strictly necessary
Under EU interpretation, this includes IP addresses if they're stored or used to track individuals across visits. Aggregated, anonymized counts that cannot be tied back to an individual fall outside this trigger.
The Architecture
How the new site passes the test
Every architectural choice below is deliberate. Together they keep the site outside all three triggers.
No cookies. No localStorage. No persistent visitor identifier. Uses an anonymized signal (a daily-rotating hash of IP + user-agent) to estimate unique visitors, then discards the inputs. Aggregated metrics only.
Cookieless human-verification challenge. Replaces Google reCAPTCHA, which sets tracking cookies and ships visitor data to Google's US infrastructure.
No Meta Pixel, LinkedIn Insight Tag, Google Ads conversion tracking, or any other advertising tracker on the public site at launch.
The public marketing site shows the same content to every visitor. No login, no preferences, no per-user state. Nothing to remember between visits.
Fonts are bundled with the site and served from Cloudflare's CDN, not loaded from Google Fonts. Some EU courts have ruled that loading fonts directly from Google exposes visitor IP to Google without consent. Self-hosting avoids the issue entirely.
Videos hosted via Cloudflare Stream are cookieless. If YouTube embeds are ever needed, the youtube-nocookie.com embed mode is used, which avoids YouTube's tracking cookies until the visitor actually presses play.
The “Strictly Necessary” Exemption
A few cookies still exist. They don't trigger consent.
GDPR carves out an exemption for cookies that are strictly necessary to deliver the service the visitor explicitly requested. Security and abuse prevention fall under this exemption. Login session cookies on the admin panel fall under this exemption.
Cloudflare security cookies (__cf_bm and similar)
Cloudflare sets short-lived cookies for bot management, abuse prevention, and challenge state during attacks. These fall under the 'strictly necessary' exemption in GDPR's ePrivacy directive: cookies required to deliver the service the visitor explicitly requested (a working, secure website) do not require consent.
CSRF tokens and session cookies on the admin
The admin panel sets a session cookie when an authorized user logs in via Entra. This is also strictly necessary: the user requested the service of being logged in. The public marketing site has no equivalent because it has no logged-in users.
If LeoLabs Adds These Later
What would trigger a consent banner
The architecture is designed to avoid these by default, but LeoLabs may decide to add some later. Each one shifts the site from “no banner required” to “banner required.” The list below is the honest map of what introduces the requirement.
Sets persistent cookies, transmits visitor data to Google's US infrastructure, and tracks individuals across sessions.
Meta Pixel, LinkedIn Insight Tag, Google Ads conversion tracking, TikTok Pixel, etc. Cookies plus cross-site tracking plus data sent to third parties.
Most A/B testing platforms (Optimizely, VWO, Google Optimize successors) set cookies to keep a visitor in the same variant across pageviews.
Anything that remembers visitor preferences, shows different content per visitor, or tracks behavior across sessions requires either a cookie or localStorage tied to that visitor.
Standard YouTube embeds set DoubleClick tracking cookies on page load. Switch to the youtube-nocookie embed mode to avoid this.
Loading a font directly from fonts.googleapis.com sends the visitor's IP to Google. Self-hosting the font avoids the trigger.
Most live chat tools (Intercom, Drift, Zendesk Chat, Crisp) set cookies for session continuity and analytics.
If a Banner Is Ever Needed
How we'd implement it
If LeoLabs decides to add one of the features above, a custom lightweight banner is built. No third-party consent vendor is introduced. The user's choice is stored in localStorage (which is technically not a cookie, so there is no ironic consent-to-cookies-by-setting-a-cookie loop). Tracking scripts load conditionally based on the stored choice. The banner is small, fast, and stays inside the same security boundary as the rest of the site.
Net Result
No banner required at launch. Legal as designed.
The new site is compliant with GDPR, ePrivacy, and CCPA at launch without showing a single consent banner. Cloudflare Web Analytics, Turnstile, the strictly-necessary security cookies, and the absence of third-party trackers add up to a site that legitimately doesn't need consent.
The story for LeoLabs is simple: we've designed the site to avoid every category of tracking that requires consent in any major jurisdiction.If LeoLabs marketing later decides the analytics depth from cookie-based tools (like GA4) is worth the consent banner, that's a deliberate trade and the banner becomes part of that decision.
Capabilities
What Your New Site Can Do
A static site is not a limited site. Here is a complete breakdown of capabilities, workarounds, and what is intentionally excluded.
✓ Full Capabilities
⚠ Requires Workarounds
Comments / Discussion
Third-party embed (Disqus, Giscus) or link to social media discussion. Not recommended for a defense contractor's marketing site.
Live Chat
Third-party widget (Intercom, Drift, Crisp). Loads as a JavaScript snippet. No server-side integration needed.
✕ Not Possible (But Not Needed)
User Accounts on Public Site
LeoLabs' website is informational. There are no user accounts, no login, no user-generated content on the public site.
Server-Side Personalization
Personalized content requires a server. The marketing site shows the same content to everyone, which is exactly what you want for security.
E-Commerce / Payment Processing
LeoLabs does not sell products through its website. If this changes, Stripe Checkout or similar can be integrated without a server.
Technology Comparison
Current vs. Proposed Stack
Supply Chain
Defending the Build Pipeline
The most active threat to a modern web project is a compromised npm package silently shipping malicious code into the build output. Recent incidents at Vercel and Axios are concrete examples. These defenses run on every change, every deploy, and every dependency update.
package-lock.json pins every dependency to an exact version and hash. Builds use npm ci, never npm install. A compromised version cannot enter production silently.
Every pull request runs npm audit. High or critical advisories fail the build. Catches known-bad versions immediately after public disclosure.
Socket.dev or Snyk monitors every package for suspicious behavior, maintainer changes, or obfuscated code. Catches malicious packages before public advisories are published.
Renovate or Dependabot opens PRs for patch and minor updates weekly. Each update is reviewed in a normal code review before merging.
Any third-party script that cannot be self-hosted is loaded with an SRI hash. The browser refuses to execute the script if it has been modified.
GitHub Actions runners are ephemeral and have access only to the secrets they need. A compromised package cannot persist or pivot between builds.
Every production deploy is traceable to a Git commit. If a malicious package is later discovered, the affected deploys can be identified by lockfile state at deploy time.
Long-Term Architecture
The Last Rebuild You'll Ever Need
This architecture is designed to be permanent. Not “good for five years.” Permanent.
Compliance Frameworks We've Considered
As an informational website with no stored customer data, no payment processing, and no user accounts, most compliance frameworks do not directly apply. We've reviewed each one to confirm this and to ensure our architecture doesn't create issues if LeoLabs' compliance posture expands in the future.
SOC 2 TYPE II
Does not apply. SOC 2 covers organizations that store, process, or transmit customer data. This website does none of those things. If LeoLabs ever adds customer-facing services to the site, the static architecture and Cloudflare-native data layer are already SOC 2 compatible by design.
FEDRAMP
Does not apply. FedRAMP covers cloud services that host federal government data. The LeoLabs marketing website does not host or process government data. Cloudflare itself is FedRAMP authorized, which provides an additional layer of confidence in the infrastructure.
NIST 800-171 / CMMC
Does not apply. These frameworks govern systems that handle Controlled Unclassified Information (CUI). The public website is not a CUI system. No controlled technical data is published on the marketing site.
ITAR / EAR
Addressed proactively. While the marketing site should not contain export-controlled technical data, our architecture includes country-level blocking for adversary nations (China, Russia, Iran, North Korea) as a default security posture. This aligns with ITAR best practices even where not strictly required.