GLITTER
Go to home

Glitter infrastructure, structured overview.

A clear view of how glitter.kr is organized: edge routing, microservices, DNS, mail, and the underlying host.

A personal cloud with structured layers.

All traffic enters through Nginx and is routed to focused FastAPI services. DNS and mail are operated as self-owned layers, forming a trust base fully controlled by the operator. This page shows the system structure at a glance.

Trust BoundaryIsolation

Public surfaces are intentionally limited; internal services remain loopback-bound and unreachable from the internet by binding.

Exposure is explicit, not accidental: binding defines reachability.

Public edge80/443 via nginx; mail and DNS ports as required
Application upstream127.0.0.1:8000 (loopback)
Data layer127.0.0.1:3306/5432/6379 (loopback)
Policy verificationPolicy Drift Detector validates bindings and key policy signals

Internet → nginx edge → app (loopback) → data services (loopback)

This model avoids external reverse proxies; verification is performed using public records and local observability.

🌐 Edge: Nginx front door

Receives HTTPS, terminates TLS, serves static assets, and routes traffic to the correct FastAPI backend. No external proxy is placed in front of it.

🧩 Microservices: FastAPI layer

glitter.kr for the main console, glitter.bz and glitter.im for checks and status, msg.glitter.kr for messaging, and captcha.glitter.kr for in-house captcha.

🔐 Core: DNS and mail

BIND with DNSSEC signs the zones, while SMTP and IMAP services handle mail delivery for glitter domains.

🖥️ Host: personal environment

All of this runs on a Self-hosted physical server, with volumes organized for code, logs, and service data, forming a quiet, operator-owned cloud.