Loading
BlueGreen runs on a serverless AWS core in Sydney with a global CloudFront edge, DynamoDB-backed data, per-tenant isolation and an integration fabric for Shopify, WooCommerce and BigCommerce. This page describes the real system — no metaphor fog.
A Next.js application delivered through OpenNext on serverless AWS: CloudFront at the edge for caching and TLS, Lambda for rendering and APIs, DynamoDB for product and content data, S3 for media, and an AI services layer for search, recommendations and drafting. Everything is multi-tenant by construction.
Requests arrive at CloudFront, which serves cached HTML and assets from the nearest edge location and forwards dynamic requests to the regional application. Host-based routing resolves the tenant — the corporate site, a tenant storefront such as elgati.com.au, or an operator host — before the application renders, so tenant scope is settled at the perimeter. Application data lives in DynamoDB with tenant keys in every query; media lives in S3 behind the CDN; and the AI services that power search and recommendations read the same catalogue data the storefront renders.
Edge layer. CloudFront terminates TLS, enforces security headers (HSTS with preload, nosniff, frame-options, referrer policy), compresses with Brotli, and caches per-route — long-lived immutable caching for assets, tuned s-maxage for HTML with revalidation, and no-store for anything authenticated. Vanity hosts redirect permanently to the canonical apex so signals never split.
Application layer. A Next.js App Router codebase rendered by serverless functions. Marketing and content pages are statically generated or ISR-refreshed (revalidate on the order of an hour), which is why they serve from the edge in milliseconds; genuinely dynamic surfaces — the blog engine, the Command Centre, account flows — render per request. A middleware layer (Next proxy) handles host routing, redirect enforcement and access rules before pages run.
Data layer. DynamoDB carries structured operational data — blog and content tables keyed by tenant, catalogues, workflow state — chosen for predictable single-digit-millisecond access and automatic scaling. S3 carries media and optimised assets. The design rule that matters: one authoritative copy of product data per tenant. Every surface reads that spine; no feature keeps a private shadow copy.
AI services layer. Search, recommendations and drafting services consume catalogue data through retrieval (RAG) so answers and generated content are grounded in what actually exists. Usage passes through cost guardrails with per-tenant telemetry — see enterprise governance for the control model.
Integration fabric. Connectors for Shopify, WooCommerce and BigCommerce sync products, pricing and inventory in both directions, and a documented API surface serves headless storefronts and back-office systems. Connectors speak platform APIs — no fragile screen-scraping.
Tenant identity is derived from the request host at the edge, carried through the request context, and applied as a hard scope on every data operation. A tenant's data, media and configuration live under its tenant key, and cross-tenant access is denied by default rather than filtered by convention.
| Guarantee | How it is enforced | What it prevents |
|---|---|---|
| Host-scoped identity | Tenant resolved from host before app code runs | One tenant reaching another via crafted URLs |
| Storage-level scoping | Tenant key required in every data access path | Cross-tenant reads or writes at the data layer |
| Route policy | Private/control-plane routes blocked per host | Operator surfaces leaking onto public hosts |
| Media isolation | Per-tenant media namespaces on S3 + CDN | Catalogue imagery crossing storefronts |
| Audit scope | Logs recorded per tenant with actor identity | Untraceable cross-tenant actions |
Because the expensive work is moved away from the request path. Static marketing pages are prerendered and served from the edge; dynamic pages render in-region with tuned caches; media ships as pre-optimised WebP/AVIF under a strict size budget; and fonts are self-hosted so no render-blocking third-party font round-trips exist.
Performance work is continuous rather than a one-off: hero media follows a poster-first strategy so the largest contentful paint is a lightweight static image; the LCP image is fetched with high priority; decorative media loads only after the page is idle; and every indexable page is server-rendered so crawlers — including AI crawlers that never execute JavaScript — see complete HTML. The features page lists the platform capabilities this architecture unlocks.
Deployment is infrastructure-as-code (SST) with a pinned AWS account and region, guardrail checks before any AWS operation, and build validation before deploy. Rollouts are stage-based — validation stage first, then production — and the same codebase serves the corporate site, tenant storefronts and operator consoles with host-scoped behaviour. Monitoring covers function health, cache-hit rates and cost telemetry per tenant, so both engineering and finance see the same truth.
The corporate B2B site (this one) and B2C tenant storefronts share the platform deliberately: every new tenant storefront — like elgati.com.au — strengthens the same spine, and a security model reviewed once covers everyone riding on it.
Infrastructure-as-code deploys run through a stage pipeline: a validation stage first, then production, with the AWS account and region pinned by guardrails and a Turbopack build gate before anything ships. Content changes flow through ISR revalidation and CDN invalidation, so pages refresh in minutes without a full redeploy.
The operational rule mirrors the commerce rule: nothing risky ships unattended. Deploy scripts verify the caller identity against the pinned account before touching AWS, invalidate the CDN deterministically, and finish with smoke checks — including an SEO smoke that re-verifies the sitemap, the homepage, llms.txt and server-rendered blog articles after every deploy.
Multi-tenant ecommerce architecture runs many independent storefronts or workspaces on shared infrastructure while keeping their data, configuration and access strictly isolated. Each tenant — a brand, client store or faculty — gets the economics of a shared platform with the safety of a dedicated one.
Tenant identity is resolved at the edge from the request host, every data access is scoped by tenant key at the storage layer, and cross-tenant routes are blocked by policy. Isolation is enforced in the platform core rather than depending on application code being careful.
Because commerce traffic is spiky and cost-sensitive. Serverless scales to a launch-day peak and back down with zero capacity planning, and you pay for actual usage rather than idle servers — which fits both SMB budgets and enterprise cost reviews.
The primary region is AWS ap-southeast-2 (Sydney), Australia. Storefronts and assets are served through a global CloudFront edge network, so overseas shoppers get edge-cached performance while data at rest stays in-region.
Static and ISR pages are served from the CDN edge with cache headers tuned per route; dynamic responses run through optimised serverless handlers with regional latency. Media ships in modern formats (WebP/AVIF) under a strict asset budget.
Book a 25-minute demo with the engineering team — we will walk your reviewers through the isolation model, data flows and deployment pipeline against your requirements.