Sevendyne platform architecture

1. What Sevendyne achieves

Sevendyne is a hiring and payroll platform delivered from a single domain (sevendyne.com). Employers sign up free, post jobs, browse candidates, and open Payrolls for invoices and compliance; candidates sign up, build profiles, and apply — all without separate SaaS products. A hub client switcher isolates payroll and jobs data per organisation (e.g. Sevendyne vs sandbox tenants).

Not on sevendyne.com: Engages (marketing CRM, lead finder, outreach) and Devkits (academy, interview prep) live in the Ansif personal workshop (ansif/ansifi.github.io/) — local dev only unless deployed separately.

Company: Sevendyne Consultancy Services LLP operates the hiring and payroll platform at sevendyne.com. The hub client switcher isolates payroll and jobs data per organisation (production vs sandbox tenants).

2. System context

flowchart TB
  subgraph users [Users]
    Team[Internal team]
    Candidates[Candidates / employers]
  end
  subgraph dns [DNS]
    Apex[sevendyne.com]
    Www[www.sevendyne.com]
  end
  subgraph gcp [GCP asia-southeast1]
    Web[empever-web nginx hub + gateway]
    HR[empever-hr Next.js + Django]
    Jobs[empever-jobs static + Flask]
  end
  Team --> Apex
  Team --> Www
  Candidates --> Apex
  Apex --> Web
  Www --> Web
  Web -->|/hr/| HR
  Web -->|/jobs/| Jobs
  HR --> PayrollDB[(Payroll DBs per client)]
  Jobs --> PortalDB[(Candidates workspace DB)]
                    

Request flow (production):

1. Browser hits https://sevendyne.com/hr/login.
2. DNS resolves to Cloud Run domain mapping on empever-web.
3. empever-web nginx matches location /hr/ and proxies to SEVENDYNE_HR_UPSTREAM, preserving the path prefix.
4. empever-hr serves the Next.js shell and Django HRMS behind its own nginx layer.

Hub static assets (index.html, login/, js/, config/) are served directly from empever-web without proxying.

3. Monorepo layout

empever/
├── index.html, login/, hub/, workspace/, invest/   # Static hub
├── js/, css/, config/                               # Shared hub runtime
├── architecture/                                    # This page
├── docker/                                         # Hub Dockerfile + nginx
├── scripts/                                        # Deploy, gateway, auth
├── payrolls/                                       # HR department
├── jobs/                                           # Hiring — talent apply & employer hire
└── Dockerfile + cloudbuild.yaml                    # empever-web build

# Moved out of this repo (Ansif personal workshop):
#   ansif/ansifi.github.io/marketing/   → Engages (CRM, lead finder)
#   ansif/ansifi.github.io/devkits/     → Devkits (academy, interview prep)

Hub (repo root)

Static HTML + JavaScript — no Node server in production. Key files: config/platform-clients.json (client registry), config/platform-nav.json (nav paths), js/platform-clients.js (URL builder), js/master-auth.js (hub login → Jobs API POST /jobs/api/auth/hub-login).

HR — payrolls/

Stack: Next.js + Django HRMS + nginx · Service: empever-hr · Path: /hr/

Jobs — jobs/

Stack: Static HTML + Flask API · Service: empever-jobs · Path: /jobs/. Separate employer and candidate login pages, workspace auth, shortlists, interview pipeline. Payrolls embeds in employer workspace via iframe.

4. Gateway architecture

Production uses a single ingress service (empever-web) with nginx path proxies — one TLS certificate, one domain mapping, two upstream backends (/hr/ and /jobs/).

docker/start-sevendyne-web.sh renders the gateway config via envsubst when SEVENDYNE_HR_UPSTREAM and SEVENDYNE_JOBS_UPSTREAM are set; otherwise it falls back to static-only nginx (hub works; /hr/ and /jobs/ 404).

After deploy, scripts/configure-sevendyne-gateway.sh discovers each Cloud Run URL and sets upstream env vars on empever-web.

5. Platform clients (multi-tenancy)

Sevendyne is a multi-client platform. The hub Switch client picker drives isolated data and outbound identity across departments.

Hub Switch client
  → sessionStorage: empever_platform_client
  → App URLs: ?platform_client= & ?payroll_db=
  → API headers: X-Sevendyne-Platform-Client
  → Jobs SQLite: per jobs_tenant
  → Payroll DB: per payroll_db key

Default clients: sevendyne (production ICP) and dummy_client (sandbox).

6. Authentication architecture

There is no single sign-on across all apps today. Each department maintains its own session, coordinated by a global auth switch and hub master login.

Global switch: config/platform-auth.json · Toggle: scripts/enable-platform-auth.sh / disable-platform-auth.sh

Public pages (no team login): home (/), /architecture/, /invest/, and Jobs employer/candidate signup. Team operators use /login/ and /hub/ only.

Production defaults (June 2026)

Employer and candidate logins are separate pages — logout returns to the matching role page with ?signed_out=1. Payrolls embedded in the Jobs employer workspace skips a second HR login when the iframe carries empever_embed=1.

deploy-sevendyne-gcp.sh runs configure-sevendyne-production-auth.sh when SEVENDYNE_HUB_PASSWORD is set.

7. GCP deployment architecture

Region: asia-southeast1 · Project: ${SEVENDYNE_PROJECT_ID}

SEVENDYNE_GCP_PROJECT=${SEVENDYNE_PROJECT_ID} bash scripts/deploy-sevendyne-gcp.sh

Deploy pipeline: enable auth → bootstrap GCP → build & deploy 3 services (parallel by default) → wire gateway upstreams → optional production auth secrets.

gcloud beta run domain-mappings create --service=empever-web --domain=sevendyne.com --region=asia-southeast1
gcloud beta run domain-mappings create --service=empever-web --domain=www.sevendyne.com --region=asia-southeast1

Deploy performance & timing

A full platform deploy via deploy-sevendyne-gcp.sh typically takes 10–15 minutes with parallel builds. Individual service deploys are faster; every gcloud builds submit still runs the full Cloud Build pipeline.

Observed build times (${SEVENDYNE_PROJECT_ID}, June 2026)

Why deploys can still take long

1. HR upload is ~1.2 GiB — payrolls/ may bundle local node_modules without .gcloudignore.
2. Full Cloud Build pipeline per service — compress → upload → docker build → push → Cloud Run revision.
3. Deploy only what changed — bash scripts/deploy-sevendyne-gcp.sh web or jobs for day-to-day updates.

Single-service deploys

# Hub only (architecture page, index.html, etc.)
bash scripts/deploy-sevendyne-gcp.sh web

# Jobs only
bash scripts/deploy-sevendyne-gcp.sh jobs

# HR only
bash scripts/deploy-sevendyne-gcp.sh hr

What would speed up deploys

8. Local development architecture

Local dev does not mirror production path routing by default. Each app runs on its own port.

./docker-up-all.sh
bash scripts/run-localhost.sh

9. Cross-app integration

• Shared platform chrome — EmpeverPlatformBar in HR and Jobs; platform-nav-bar.js on hub.
• Hiring pipeline — Jobs shortlist API, interview confirm links, in-app notifications; employer status updates through to payroll onboarding (manual today).
• Payrolls embed — Employer workspace opens HRMS in iframe with empever_embed=1 and payroll_db= from client switch.
• Hub shell — /hub/#/{app} loads department apps in an iframe shell (Payrolls primary; Engages/Devkits link out to Ansif workshop in local dev).

10. Optional Engages bridge (local dev)

Jobs still includes Python bridges (markets_employer_leads.py, markets_candidate_leads.py) that call an Engages/Marketing API at MARKETS_API_BASE (default http://127.0.0.1:5050) for skill-matched project leads and external job posts. This integration is not wired in production on sevendyne.com — Engages runs in the Ansif workshop when started locally alongside Jobs.

Local-only request flow:

1. Jobs UI calls POST /jobs/api/workspace/me/project-leads/match (employer) or matched-jobs endpoints (candidate).
2. Flask forwards to Engages POST /api/portal/employer/:user/match-projects or candidate equivalents.
3. Engages scans web_intel_leads pool via profileSkillLeadMatch.js when the workshop stack is running.

Production hiring on sevendyne.com uses employer-posted jobs and the candidate roster — not the Engages lead pool.

11. Data layer

Production persistence (GCS)

Cloud Run has no persistent disk. Each data service syncs SQLite to gs://${SEVENDYNE_PROJECT_ID}-sevendyne-db via SEVENDYNE_DB_GCS_BUCKET:

Boot: GCS restore → app start → backup on shutdown (HR: every 5 min). Git SQL seeds run only when SEVENDYNE_FORCE_SEED_DB=1 — never on routine redeploys. empever-hr stays at max-instances=1 (SQLite single-writer). See jobs/docker/CLOUD_DB_TODO.md.

12. Operational scripts

13. Related systems

14. Current state (June 2026)

15. Known gaps

1. Legacy hub JS — Some js/platform-*.js files still reference marketing/technical paths; nav JSON lists Engages/Devkits as external localhost apps.
2. Project ID drift — Older docs reference ${SEVENDYNE_PROJECT_ID}; live deploy uses ${SEVENDYNE_PROJECT_ID}.
3. No SSO — Hub login gates workspace but does not issue tokens for HR or Jobs sessions.
4. GCS stopgap, not Cloud SQL — SQLite file sync survives redeploys; Payrolls should migrate to Cloud SQL long-term.
5. payrolls/.gcloudignore — Missing; HR deploy may upload ~1.2 GiB including local node_modules.
6. Engages bridge — Jobs → Marketing API code remains for local workshop dev; not used in production gateway.

16. Architecture principles

1. One domain, three services — Users see sevendyne.com; operators deploy web + hr + jobs on Cloud Run.
2. Hub is static + gateway — Minimal hub container; HR and Jobs complexity lives in child services.
3. Client switch is the tenancy boundary — Registry JSON + query params, not separate subdomains.
4. Free public hiring surface — Home, Platform, Investors, and Jobs signup/login are public; team uses /login/.
5. Independent deployability — Each cloudbuild can run alone; gateway script reconnects upstreams.
6. Workshop split — Engages and Devkits live in Ansif personal workshop; Sevendyne focuses on hiring + payroll.