All inbound traffic arrives on port 443 (HTTPS). Nginx terminates TLS via Let's Encrypt and routes internally on localhost. Port 80 issues a 301 redirect to HTTPS on all vhosts. Static frontends are served directly from disk — no proxy hop. Odoo is not behind Nginx — it runs on its own droplet with ports 8069 and 8072 exposed directly on the host.

• ✓TLS everywhere — Let's Encrypt, auto-renew via certbot. Port 443 only.
• ✓Password SSH disabled — RSA key-based access only on all servers.
• ✓Database not exposed — PostgreSQL accessible only within VPC private network.
• ✓Internal service comms — Medusa ↔ DES ↔ Odoo communicate over localhost / VPC-internal network only.
• ✓Separate VPCs — Production and QA are isolated VPCs; no cross-environment traffic.

Pending security gaps and go-live blockers are tracked in Security Index.

• ✗ Enforce secret validation at startup
  JWT_SECRET and COOKIE_SECRET fall back to "supersecret" if env vars are missing. Add a startup check that throws a fatal error if any required secret is absent or still the known default.
• ✗ DigitalOcean Cloud Firewall — all servers, port 443 only public
  All droplets (QA and Prod) must have a DO Cloud Firewall applied: allow inbound 443 from anywhere, allow 22 from trusted IPs only, block everything else. Applies to App Droplet, DES Droplet, and Odoo Droplet in both environments.
• ✗ RabbitMQ management UI locked down (port 15672)
  Port 15672 is publicly reachable without a firewall. Block via DO Cloud Firewall and access only via SSH tunnel: ssh -L 15672:localhost:15672.
• ✗ Block public access to Data Exchange dashboard
  The DES dashboard (dataexchange.sesame.market/dashboard.html) must not be publicly accessible. Restrict via Nginx basic auth or IP allowlist.
• ✗ WAF / DDoS protection via Cloudflare
  Proxy all public domains through Cloudflare (free tier minimum). Enable WAF managed rules and rate limiting on /store/auth, /store/carts/complete, and password-reset endpoints.
• ✗ Stripe webhook signature verification
  Confirm all Stripe webhook endpoints verify the Stripe-Signature header. Unverified webhooks can be spoofed to trigger fraudulent order state changes.
• ✗ DES webhook payload validation
  Confirm the DES action enum rejects all unknown event types to prevent injection via malformed webhook payloads.
• ✗ ORDER_CANCELLED handler — stub not implemented
  When a buyer cancels in Medusa, the DES handler does nothing. Odoo sale order stays "confirmed", causing inventory and billing discrepancies. Implement order.handler.ts:150 before go-live.

• ✗ Verify SSL configuration on all domains
  Confirm Let's Encrypt certificates are active, auto-renewing, and correctly configured on all domains (QA + Prod): storefront, admin, logistics, TCMS, dataexchange, and opshub (Odoo). Check for mixed-content warnings and HSTS headers.
• ✗ Production approval gate for deployments
  Add a GitHub Environment protection rule requiring at least one approver before any production deploy job starts.
• ✗ Uptime monitoring + alerting
  Configure UptimeRobot or DO Monitoring HTTP checks on all public endpoints with Slack/email alerts. Also alert on DLQ size > 0 and disk usage > 80%.
• ✗ Log rotation + off-server log storage
  Install pm2-logrotate (max 50MB, 7 days retention) on all PM2 droplets. Ship logs to Logtail, Papertrail, or S3.
• ✗ Odoo PostgreSQL backup policy
  Odoo DB runs in Docker with a local volume — no automatic backup. Add a daily cron pg_dump + sync to DO Spaces. Enable Droplet-level weekly backup as secondary safety net.
• ✗ Mounted volume backup policy
  Product images and assets are on a DO Volume with no snapshot schedule. Enable DO Volume Snapshots daily or sync to Spaces via cron.
• ~ Webhook retry / circuit breaker (Medusa → DES)
  Medusa fires a single HTTP POST with no retry. If DES is down, events are silently lost. Add retry with exponential backoff to webhook-service.ts.
• ~ Production branch protection
  develop is protected with peer review. main has no approval gate. Add GitHub Environment protection rules.
• ~ Odoo deployment — no QA gate
  Odoo deploys on push to main. Should follow feature → develop → main with a QA Odoo environment before production changes land.
• ~ DES rollback workflow
  Rollback workflows exist for Medusa, Admin, and Storefront, but not DES or Odoo. Create rollback YMLs before go-live.

• ~ QA / Prod service version parity
  Confirm QA and Production run identical versions of all service modules. Streamline so QA always mirrors what will be promoted to Prod.
• ~ Encryption at rest — verify all volumes
  DO Managed PostgreSQL encrypts at rest by default. Verify the Odoo Droplet's local PostgreSQL Docker volume and the mounted assets volume.
• ✗ Logistics Dashboard production deploy workflow
  No production deploy or rollback workflow exists. Create before go-live to avoid manual SSH deploys under pressure.
• ✗ SonarQube & Snyk — SAST and dependency scanning
  Neither tool is integrated yet. SonarQube provides static code analysis and security hotspot detection on every PR. Snyk scans npm dependency trees and the Odoo Docker image for known CVEs. See CI/CD tab for the full integration plan.
• ✗ Google Analytics integration
  GA4 not yet integrated on storefront or admin UI. Add before go-live so day-one traffic is tracked.

• ✓TLS on all public endpoints — Let's Encrypt, auto-renewed via certbot, HTTPS-only on port 443.
• ✓RSA-key SSH only — Password authentication disabled on all droplets.
• ✓Database not publicly accessible — PostgreSQL accessible only within VPC private network.
• ✓Separated environments — Production and QA on separate VPCs, no cross-environment traffic.
• ✓API key auth on DES — Webhook endpoints require X-API-Key. Admin endpoints require Bearer token.
• ✓JWT + actor-based auth on Medusa — Separate auth actors (store, admin, logistics) with scoped tokens.
• ✓Secrets injected at deploy time only — GitHub Actions Secrets used; .env files never committed.
• ✓No PII in logs — Logging standards prohibit email, phone, address, card data, and tokens in all logs.
• ✓Audit log module — Database-level audit triggers on all Medusa tables.
• ✓Stripe authorize-only pattern — Payments authorised at checkout, captured post-order only.
• ✓Daily DB backup (Prod) — DO Managed PostgreSQL automatic daily backups, 7-day retention.
• ✓RBAC roles — Three logistics roles with scoped permissions enforced at API level.

Full branching strategy including hotfix flow is documented in the Developer Guide → Branching Strategy section.

• ✗qa-medusa is running Ubuntu 25.04 — this image is marked retired by DigitalOcean. Should be upgraded or rebuilt on 24.04 LTS or 25.10.
• ✓prod-medusa runs Ubuntu 25.10 (latest base image available at creation time).
• ✓prod-odoo, qa-odoo, prod-des, qa-des all run Ubuntu 24.04 LTS — stable and supported.

Documentation for local development setup will be added here.

• ✗Odoo — branching not yet streamlined; deploy still runs directly from main via shell script.
• ✗TCMS — no deploy workflow yet; deployed manually.
• ✗Logistics Dashboard — no production deploy workflow; QA only.

The Store Front (simplifab-v2) is the main web application that buyers and producers interact with daily. It is a role-based platform — the experience differs significantly depending on whether you are logged in as a Buyer or a Producer. There is also a public-facing marketing layer (home page, how it works, producer profiles) accessible without an account.

All meaningful commerce functionality sits behind authentication. Account creation requires admin approval — see the Onboarding Process playbook for how users get access.

This single flow handles two situations: a user who has forgotten their password, and a user who never activated their account (e.g. the setup link expired before they clicked it). Both are handled via /forgot-password.

A logged-in user can change their password from their account settings. The path depends on account type:

All incoming applications are found under the Applications section in the Admin panel. There are three views:

The application detail page shows four sections. Review all of them before making a decision.

Click Edit on the application detail page to open the Review Application drawer. The first decision is whether to approve or reject.

The Customer Group field determines which price list the customer will see across the platform. Every price list is linked to one or more customer groups — so assigning a customer to a group effectively sets their pricing tier.

The credit feature allows selected customers to purchase on credit up to a defined limit, rather than paying at checkout immediately. This is an optional, opt-in feature — most customers will not have it enabled at onboarding.

When approving a Producer, one additional option appears in the Review Application drawer:

• ✗Open the Review Application drawer → set Status to Rejected
• ✗Enter a clear Rejection Reason (minimum 10 characters) — this is stored internally for audit purposes
• ✗Save
• ✗Manually contact the applicant — no automated rejection email is sent. Use the contact email from the application
• ✗Rejected applications are visible in the Rejected view for future reference

These actions can be performed at any time after approval from the Customer or Application detail page.

The Ecom-Backend (simplifab-ecom-server) is the backbone of the Sesame platform. Every action a buyer or producer takes on the storefront — registering, browsing products, placing an order, requesting a delivery slot — is processed and stored here. It also drives the Admin panel, the Logistics portal, and the Data Exchange Service that syncs orders into Odoo.

Built on Medusa v2 (an open-source commerce framework), it has been extensively customised with 13 bespoke modules covering food-specific product data, B2B organisation management, delivery logistics, sourcing briefs, and more.

13 custom modules extend the core commerce platform with Sesame-specific business logic.

The Logistics portal (Logistics-V1) is an internal tool used exclusively by the Sesame logistics team — not by buyers or producers. Its job is to bridge the gap between an incoming customer order and a confirmed, scheduled delivery. New orders flow in automatically from the Ecom-Backend and appear in the portal waiting to be assigned a delivery slot or routed to a courier.

The dashboard refreshes automatically every 10–30 seconds so the team always sees live order data without needing to reload the page.

The Admin panel (administration) is an internal tool used by the Sesame team — ops staff, account managers, and platform administrators. It is not visible to buyers or producers. It covers everything from approving new business applications and managing the product catalogue, to processing orders, setting pricing, and configuring platform-wide rules. Order management is the default landing view, reflecting the primary daily workflow for the ops team.

Odoo acts as the operational system of record for the Sesame marketplace. While buyers and producers interact with the storefront, the commercial and fulfilment reality lives in Odoo — stock levels, purchase orders, sale orders, supplier pricing, and financial settlement all flow through here. It is not directly visible to buyers or producers; they experience its effects through order confirmations, delivery updates, and product availability on the storefront.

Four custom modules form a single integration pipeline: products defined in Odoo flow out to the Medusa storefront; orders placed on Medusa flow back into Odoo as sale orders; and completed deliveries tracked via Detrack push status updates back to both Odoo and Medusa in real time.

Four custom modules extend Odoo 19 with Sesame-specific business logic.

• ✓Initial release — Network Topology diagram with Production and QA VPC layout.
• ✓System overview — droplet map, Nginx entry points, and service inventory.