Web infrastructure

365 Networking

The web infrastructure of Snowdaddy Solutions: one public edge that serves every site from its own account, the creator platform 365Entertainment, the image engine ImageForge, and the engines of the 365 family. Separate engines, each built for one job, each leaning on the next. What runs is said to run; what is built is said to be built.

  • One public edge: TLS for every name, one account per site
  • Every release signed and verified before it installs
  • 365Entertainment in production, with its own sealed storage
  • ImageForge draws every icon and share card on these sites

The map

Separate engines, one house

Select an engine to see what it leans on and what leans on it. The upper half runs today; the lower half is built or designed and waits, each piece with its status.

The 365 Networking map: engines in production above, engines built below; select one to see what it leans on and what leans on it IN PRODUCTION BUILT OR DESIGNED, NOT RUNNING ImageForge image engine 365Entertainment creator platform The static sites snowdaddy.net, 365 The public edge TLS for every name Dove link GPU server Security relay console, alerts 365Hosting sign-in, dashboard 365Vault split, sealed 365Payments Monero flow 365Business field operations Key split 3 of 4 shares 365Proxy origin hiding

The public edge in production

One server terminates TLS for every name and redirects plain HTTP. Each site has its own account and its own web root, served as static files with symlinks refused and only GET allowed. Releases are built and signed on the production workstation and verified against a pinned key before anything installs; every published version is kept for rollback.

365Entertainment in production

The creator platform: public site, creator Studio and staff dashboard. Every signed-in request passes one gate; identity details and logins are sealed a second time under a key derived for each purpose, on an encrypted database and an encrypted volume; the database is backed up every night, encrypted, with a rehearsed restore.

ImageForge in production

Our own image engine. It draws the icons and images of 365Entertainment on the server, and every icon, share card and home-screen icon of these sites. Its icon set is stored sealed with AES-256-GCM; it uses no image files, no font files and no outside service.

The static sites in production

snowdaddy.net and the 365 family: plain HTML and one stylesheet, nothing loaded from anyone else, a strict content security policy and no forms. Each site is published from its own signed release into its own web root, in one atomic swap.

Dove link in production

The creator assistant's private encrypted point-to-point link. It ends inside the model's container on a GPU server we operate; through it only the model answers, and from inside, the container cannot open a connection to a private network or to the server it runs on.

Security relay in production

Snowdaddy Security's console reaches the household's phone through the edge. The relay and the notification service run in rootless containers under their own unprivileged account, with an egress guard; the site keeps an outbound encrypted tunnel, so nothing listens at the customer's site.

365Hosting built

One sign-in box that sends staff and customers down separate paths; an administrator path that answers only from inside the private administration network; a customer dashboard for sites with their certificate status, databases, tickets and invoices, every query scoped to that customer. It does not serve customers today; the hosting standard itself runs on the edge.

365Vault built

A file is cut into three to five parts. Each part is encrypted with its own random 256-bit key under AES-256-GCM, ChaCha20-Poly1305 or XSalsa20-Poly1305, and neighbouring parts never share one. The part keys sit in a separate record sealed under a master key; the parts go to PostgreSQL, MariaDB and SQLite and are joined in memory on download. Every part is needed to rebuild a file. Not running today.

Key split built and tested

A key split into four shares so that any three rebuild it and two reveal nothing, over GF(2^8). Implemented and tested in code; not deployed as a distributed key.

365Payments built

A merchant's server asks for a payment and receives a one-time Monero address. The platform checks every 30 seconds; after 10 confirmations it sweeps the whole payment to the merchant's own address and tells the merchant with a webhook signed under the merchant's own secret. Built for Monero; not running today.

365Business built

Job board, dispatch, time clock, asset maintenance and payroll export, each switched on in one configuration file, with four roles enforced on every endpoint. Payroll adds up clocked hours and writes a file for the accountant; it computes no tax and pays no one. No business runs on it today.

365Proxy design

A front layer designed to keep origin servers off the public internet: visitors reach the front, never the origin. Designed; not running.

The public edge

One server, every site in its own room

The edge is where the public meets the house. It serves the static sites and the creator platform, relays the camera console, and holds the creator assistant's private link, each piece separated from the others.

TLS
Certificates issued and renewed automatically for every public name; plain HTTP answers only with a redirect; an unknown name gets no answer at all.
Sites
Each site has its own account and web root: static files only, symlinks refused, GET only, sources and dotfiles never served.
Headers
A content security policy that allows only the site itself, no framing, no referrer, HSTS.
Releases
Built and signed on the production workstation, verified against a pinned key and every file's hash before anything installs; each publish is an atomic swap with every earlier version kept.
Containers
The camera relay and the notification service run rootless under their own account, with an egress guard.
Names
Codenames, never product names; no default ports; no version banners. Every change is written into one inventory kept off the servers.
Diagram: visitors reach the public edge over HTTPS; inside it each site has its own account, releases are verified against a pinned key, and a rootless relay serves the camera console; the relay reaches the camera site through an outbound encrypted tunnel, and the creator platform reaches the GPU server through a private encrypted link Visitors HTTPS THE EDGE Snowdaddy own account 365 sites own accounts Creators 365Entertainment Signed releases verified against a pinned key Relay and notifications rootless containers, own account egress guard tunnel private link Camera site outbound only; nothing listens GPU server Dove, inside its container
The edge: the only public door, with a room for every site

Operations

How the house is run

The discipline that runs the cameras and the vehicles runs the web.

  • Checked before it runs

    A change reaches the edge only as a signed release, checked against a pinned key and file by file; the creator platform lints every file on the server before anything live is touched, archives the live tree, and verifies the site afterwards.

  • Every version kept

    Each publish keeps the version before it, and one command puts it back.

  • Nothing advertised

    No version banners, no product names on interfaces or services, no default ports for anything that listens.

  • A room per site

    Every site runs as its own account; a site's files can never reach another site's.

  • Nothing from anyone else

    No CDN, no outside fonts, no trackers; images come from ImageForge, text from the system's own fonts.

  • Everything written down

    Every interface, container, port and change is recorded in one inventory with a change record, kept off the servers.

365 Networking

Infrastructure that says what it is

The company site carries the 365 family; every 365 name has its own site on the edge.