Skip to content
Internal

Cloudflare edge — N1 IT Landscape

N1 IT Landscape — The Blueprint · CF-Access internal

Cloudflare edge

Section titled “Cloudflare edge”

N1 IT Landscape · Owner: Arun Venkataraman · source of truth: markdown SSOT

N1 IT Landscape — Cloudflare edge

Section titled “N1 IT Landscape — Cloudflare edge”

CURRENT-STATE as of 2026-06-09 · part of the N1 IT Landscape (start at Overview). Owner: Arun Venkataraman (Principal Engineer).

N1’s entire edge — DNS, WAF, Zero-Trust Access, the Tunnels that are the only way into AWS, Workers, and R2.

6. CLOUDFLARE (DNS, WAF, Zero-Trust, Tunnels, Workers, R2)

Section titled “6. CLOUDFLARE (DNS, WAF, Zero-Trust, Tunnels, Workers, R2)”

Account: N1 Research LLC (70dc91c56a526c998d57407ee163e3c8). Cloudflare is N1’s entire edge : DNS authority, the only inbound path to AWS, the identity gate, the CDN/compute for the web apps, and the public artifact store.

6.1 Zones (11)

Section titled “6.1 Zones (11)”
Zone Plan Role
n1.care Pro ($20/mo) Primary product domain (app + marketing + all customer-facing API/auth/billing)
n1-research.com Free Everything internal — all internal portals/tools, Access-gated
n1.healthcare Free Older/corporate domain; apex redirects to n1.care; holds email + legacy records
twin.healthcare Free “Twin” product (largely retired/parked)
casakanda.com, health-drive.com, healthiercompany.com, kwakea.com, myfamilyhealth.com, ratua.com, sireau.com Free Other/parked domains

All 11 zones use nameservers hugh.ns.cloudflare.com / pat.ns.cloudflare.com.

6.2 The two domains that matter

Section titled “6.2 The two domains that matter”
  • n1.care — the product. n1.care (marketing), app.n1.care (production web app), staging.n1.care (staging web app) are served by Cloudflare Workers (see §6.4). All the API, auth, billing and oauth subdomains are CNAMEs into Cloudflare Tunnels that terminate inside the EKS clusters.
  • n1-research.com — internal only. Every hostname here requires Cloudflare Access. Apex and most hostnames redirect to n1.care; the live internal tools are listed in §6.6.

6.3 WAF (Web Application Firewall)

Section titled “6.3 WAF (Web Application Firewall)”
  • 🔒 n1.care (Pro): full managed WAF is deployed — Cloudflare Managed Ruleset + OWASP Core Ruleset (both executing), Exposed-Credentials check, normalization, and L7 DDoS protection.
  • 🔒 n1-research.com (Free): has the Free-tier managed ruleset + normalization + L7 DDoS , but not the paid OWASP/Managed rulesets n1.care gets — so internal services here lean primarily on Cloudflare Access (identity), not full WAF. One custom rule skips rate limits for known office egress IPs (115.135.157.97, 34.69.34.16, 34.27.95.55, …) on litellm.n1-research.com. A redirect rule sends stray n1-research.com hostnames to n1.care.

6.4 Workers (4) and Pages

Section titled “6.4 Workers (4) and Pages”
Worker script Custom domain Role
n1care-website n1.care Marketing/public site
prodution-n1-care-app (sic — typo in script name) app.n1.care Production React app
staging-n1-care-app staging.n1.care Staging React app
n1-internal-docs internal.n1-research.com Internal engineering docs (Access-gated) — this is where the HTML version of this blueprint is published

The account has 0 Pages projects. n1.care, app.n1.care, and staging.n1.care are all served by Workers , and the React app is built and deployed on Cloudflare (not from GitHub). The plan.n1-research.com → engineering-plan.pages.dev DNS entry points at a Pages project not present in this account.

6.5 R2 object storage (2 buckets)

Section titled “6.5 R2 object storage (2 buckets)”
Bucket Created Purpose
n1-artifacts 2025-12-16 🌐 Public Python wheels — served at artifacts.n1-research.com (CNAME → public.r2.dev). Holds the N1 libraries (§16). Intentionally public.
ratua 2025-11-19 Ratua project assets

6.6 Cloudflare Access — the internal hostnames and how they’re gated

Section titled “6.6 Cloudflare Access — the internal hostnames and how they’re gated”

13 Access applications. The access model is one consistent pattern:

  1. Allow N1 Staff — allow if email domain is @n1.healthcare and login method is the Google IdP. (Gates every staff app to company Google accounts.)
  2. Allow Service Accounts — non_identity + any_valid_service_token for automation (used on SigNoz ingest, LiteLLM, ArgoCD).
  3. Deny All fallback.

Exceptions: Prod Admin Dashboard is tightened to a named allowlist of 7 emails ; N1 Artifacts Registry is public bypass (public bucket by design).

Live internal hostnames on n1-research.com (all tunnel-routed ; most are protected by a dedicated Cloudflare Access application, but a few — e.g. argocd.n1-research.com, ws-api.n1-research.com — have no individual Access app and rely on the tunnel plus the service’s own auth, as noted):

Hostname Backend Notes
admin.n1-research.com admin-dashboard (prod) Management console (§14)
staging-admin.n1-research.com admin-dashboard (staging)
argocd.n1-research.com ArgoCD (prod) 🔒 ⚠️ has no Access application of its own
argocd-staging.n1-research.com ArgoCD (staging) Access-gated; staging deploys (§7)
litellm.n1-research.com LiteLLM (AI cluster) Model gateway UI/API (§11)
litellm-staging.n1-research.com / litellm-prod.n1-research.com LiteLLM (staging/prod)
signoz.n1-research.com / ingest-signoz.n1-research.com SigNoz (dev/AI account host) Observability (§13)
langfuse.n1-research.com Langfuse 🔒 tunnel currently down
artifacts.n1-research.com R2 n1-artifacts Public wheels
internal.n1-research.com Worker n1-internal-docs Internal docs
chat.n1-research.com N1 NexAI (localhost:3080) Internal chat/AI
automated-testing.n1-research.com automated-testing (staging)
ws-api.n1-research.com staging

Identity providers: 1 — Google OAuth (“N1 Healthcare”, client 340163587470-…apps.googleusercontent.com, PKCE on). Access groups: 0 (policies are written per-app).

6.7 Tunnels (the ONLY way into AWS) and the staging-DB private DNS

Section titled “6.7 Tunnels (the ONLY way into AWS) and the staging-DB private DNS”

🔒 All inbound traffic to staging and production enters exclusively through Cloudflare Tunnels run by cloudflared pods inside each cluster. There are no public load balancers, no public IPs, no ACM certs in AWS (§8). TLS terminates at Cloudflare.

Tunnel Status Conns Serves
EKS Production (5a3b0a66) healthy 8 api/auth/billing/oauth/admin/argocd/litellm-prod
EKS Staging (03dae21f) healthy 8 api-staging/auth-staging/billing-staging/argocd-staging/litellm-staging/staging-admin/automated-testing/ws-api
EKS AI Cluster (d7bf4a5c) healthy 8 litellm.n1-research.com → litellm.llmproxy:4000
N1 NexAI (2f9140fe) healthy 4 chat.n1-research.com
signoz (4ad64177) healthy 4 signoz + ingest-signoz (→ localhost:8080 / :4318 on the SigNoz host)
N1 Langfuse (b4d155e5) down 0 langfuse
N1 Local Dev (e2fbdd23) down 0 cortex-demo

Plus retired GKE-era tunnels still referenced by dead DNS (dev-n1-gke, n1-gke, Production Cloud Run, EKS Twin Staging) — harmless 502 dead-ends, listed in findings.

🔒 Staging DB/Redis read access via WARP private DNS (Cloudflare Gateway DNS overrides): db.staging.n1 and redis.staging.n1 are not DNS records in any zone — they are Cloudflare Gateway DNS override rules that only resolve inside WARP for @n1.healthcare identities:

Friendly name (WARP-only) Resolves to
db.staging.n1 n1-staging-app.cluster-c3gc6ccoiwig.us-east-2.rds.amazonaws.com (Aurora PostgreSQL, staging)
redis.staging.n1 staging-valkey.zc3ep9.ng.0001.use2.cache.amazonaws.com (ElastiCache Valkey , staging)

This is how developers get read-only staging DB + Redis access without any public exposure: the name only exists on an enrolled WARP device. Two more Gateway rules block malware/botnet/phishing DNS categories globally and run an incident-response “CANARY” C2-block test.