Cloud architecture.
SciPHR runs on Google Cloud, designed so that the cloud is the hosting plane, never the custody plane. Every managed service in the stack exists to keep the platform available, observable, and auditable, and none of them ever holds a user key. This page walks the runtime topology, the identity model, and the keyless deployment pipeline.
Designed and operated by SciPHR's founder, a holder of the Google Cloud Certified · Professional Cloud Architect credential, Google's certification for designing secure, scalable, highly available cloud architecture.
Scope & status
The platform currently runs against the XRPL testnet. The architecture below is the same one that hardens for mainnet, the difference is configuration (cache tier, instance floors, alerting thresholds), not design. Service names are Google Cloud products; project-level identifiers are deliberately omitted.
What the cloud is trusted with.
SciPHR's custody model requires that a fully compromised backend cannot steal funds or extract key material. The cloud architecture is designed for that scenario: it assumes the backend can be breached, and keeps the system safe in that case.
Trusted with
Availability, public metadata, prepared-intent records, encrypted envelopes it cannot open. The infrastructure's job is uptime and integrity, not secrecy of user keys.
Never trusted with
Seeds, private keys, decrypt capability, signing authority. There is no signer service, no KMS-wrapped user secret, no decrypt endpoint anywhere in the deployed stack.
Why it matters
A breach of the backend yields metadata and sciphrtext, nothing that can sign or decrypt. That property holds because the boundary was set before any service was provisioned, not added afterward.
Defense in depth, in the right order
The platform still applies the full hardening playbook, least-privilege IAM, secret isolation, private egress, keyless CI/CD. Hardening reduces the chance of a breach; the custody boundary limits what a breach can reach.
A serverless core, drawn.
The backend is a stateless container on Cloud Run fronted by an edge proxy. Requests reach the origin only with a Google-issued identity token; secrets mount at runtime from Secret Manager; ephemeral state lives in Firestore with every record carrying its own expiry; private egress flows through a Serverless VPC connector.
The stack, service by service.
| Concern | GCP service | Why this one |
|---|---|---|
| Compute | Cloud Run | Stateless containers, request-scoped scaling down to zero. A capped instance ceiling bounds both cost and blast radius. |
| Secrets | Secret Manager | Configuration mounts at deploy time as versioned references, never baked into images, never committed. Deploys fail closed if a required secret is missing. |
| State | Firestore | Serverless document store for ephemeral records. Every record carries an expiry stamp enforced on read, with Firestore TTL available to garbage-collect stale documents platform-side. |
| Cache | Memorystore for Redis | Opt-in HA tier reached only over private networking. Test environments run an in-process cache instead. |
| Private networking | Serverless VPC Access | Cloud Run egress to private ranges only, so the cache and internal services are never internet-reachable. |
| Build & registry | Cloud Build · Artifact Registry | Container images built and stored inside the project, versioned per release and deployed through the pipeline in §05. |
| Async work | Cloud Tasks | Queued dispatch with bounded retries, exponential backoff, and capped concurrency, so failures retry without flooding downstream services. |
| AI guardrails | Model Armor | Screens inbound text for prompt injection, jailbreaks, and malicious URIs before it ever reaches an LLM (§06). |
| Ingress control | API Gateway | A managed public front for functions whose direct invoker access is restricted, auth handled by IAM, not application code. |
| Storage node | Compute Engine | A persistent-disk IPFS node for the encrypted envelopes, behind HTTPS and authenticated API access. |
| Observability | Cloud Monitoring | Uptime checks against the health endpoint with an alerting channel, so failed checks page before users report them. |
Short-lived identity over stored credentials.
Users trust SciPHR's backend to prepare transactions honestly and serve correct data, so the identities allowed to touch it are kept short-lived and narrow. Three places where that shows up:
Deploys without stored keys.
The classic failure mode of cloud CI/CD is a long-lived service-account key stored in a repo secret. SciPHR's pipeline holds no cloud credential at all. GitHub's OIDC provider attests the workflow's identity; Google's Security Token Service verifies the attestation and issues credentials that exist only for the life of that run, and only for workflows from this exact repository.
#the whole pipeline, no downloaded keys anywhere
$git push origin main
›quality gates · type-check + lint… ok
›auth · OIDC → Security Token Service → short-lived credentials
›build · Cloud Build → image → Artifact Registry
›deploy · new Cloud Run revision · secrets mounted at runtime
›verify · GET /api/health … 200 ok _
The feedback triage pipeline.
The same architecture patterns extend beyond the wallet backend. SciPHR's feedback triage system, which reads user feedback, classifies it with Claude, and files tracked issues automatically, is a small event-driven pipeline that shows the posture end to end:
Screened before the model
Every inbound message passes through Model Armor, prompt-injection, jailbreak, and malicious-URI filtering, before any LLM sees it. User-submitted text never reaches a model unscreened.
Queued, not coupled
Work dispatches through Cloud Tasks with bounded retries and exponential backoff. If a downstream service is unavailable, work waits in the queue and retries; nothing is lost.
Gated ingress
The function itself restricts direct invocation; public traffic enters only through API Gateway, whose own identity is the single principal allowed to invoke it.
Verified senders
Inbound events are signature-verified at the boundary, and every credential the pipeline uses lives in Secret Manager, mounted at runtime like everything else.
What changes for mainnet.
The platform runs lean on testnet, with the mainnet upgrade path already provisioned in code. Moving to mainnet changes configuration, not architecture:
- Cache moves from in-process to Memorystore HA with a replica, over the same private connector that already exists.
- Cloud Run instance floors rise from scale-to-zero to warm minimums; the container and pipeline don't change.
- Uptime checks and alerting widen from health probes to latency and error-budget alerting on the same monitoring plane.
- The custody boundary doesn't change, it was never a function of environment.
Summary
Managed, serverless, and identity-driven everywhere, so the operational surface stays small enough to audit, and no user key material ever enters the cloud.