How the platform fits together

Architecture

This is a product platform, not a monolith. The architecture is intentionally boring: reverse proxy routing, a fast core API, dedicated auth, background ingestion, and standard storage/cache/eventing.
InternetVisitors + bots(SEO + UX)Reverse proxy (TLS)Apache / Nginx / DirectAdminWeb (public)Next.js sitethemes, discover, blog, legalAdmin (operator)Next.js consoleproviders, SEO, ads, securityCore APIRust api-corecatalog, SEO surfaces, sitemapsAuthauth-servicesessions, admin policiesWorkeringestion + refreshprovider health, freshnessPostgresprimary storecatalog, config, auditRediscachefast reads, postureNATS (JetStream)events / queuedecouple pipeline
Routing model
Public traffic terminates at TLS and is routed to the public website and the operator console. Internals remain behind the proxy.
Ingestion pipeline
The worker pulls and normalizes provider data, then the core API exposes catalog and SEO surfaces. Provider health and freshness are visible to operators.
SEO surfaces
The core produces discovery routes and segmented sitemaps designed for crawl budget and canonical hygiene.
Optional AI
AI modules are optional. When enabled, they assist catalog quality and content workflows under admin control.
Stack summary
Web: Next.js
Admin: Next.js
Core API: Rust (api-core)
Auth: auth-service
Worker: ingestion/refresh
Storage: Postgres
Cache: Redis
Eventing: NATS (JetStream)
Proxy: Apache/Nginx/DirectAdmin
Why this layout
  • Public UX and operator UX are separate.
  • Ingestion runs in background workers, not request paths.
  • SEO routes and sitemaps are first-class surfaces.
  • Optional AI stays optional and operator-controlled.
Continue evaluation
Product, pricing, what's included, onboarding, and providers.

We use analytics cookies to measure performance and improve operator experience. You can accept or reject optional tracking.