Deploy a HIPAA-Compliant App in Under 10 Minutes

Spritely turns a YAML data model into a hosted application. You describe which fields hold PHI, who can read or write them, and what the app should be called. The CLI validates that schema, provisions the compliance plumbing, and pushes a live URL. The goal here is speed without hand-waving: you will see the exact commands, a realistic schema, and what the deploy output looks like end to end.

The flow is linear: install once, authenticate once per machine, then iterate on schema.yaml and redeploy when you are ready. You are not provisioning databases, wiring an ORM, or configuring a secrets manager by hand; those steps are implied by the schema and enforced on the server. If something fails, the CLI exits non-zero with a concrete error so you can fix forward without digging through cloud consoles.

Prerequisites

You need a Spritely account. During beta, signing up is free and does not require a credit card. Install Node.js 18 or newer so the global CLI can run, and use any modern terminal on macOS, Linux, or Windows via WSL. That is the full list: account, Node, shell.

Use a 64-bit Node build from nodejs.org or your package manager. If npm is missing, install Node first; the CLI does not bundle its own runtime. Corporate proxies sometimes require npm config set proxy and https-proxy before global installs succeed.

Step 1: Install the CLI

Install the Spritely CLI globally with npm. Global install keeps the spritely binary on your PATH so you can run it from any project directory.

$ npm install -g @spritely/cli

Confirm the install succeeded by printing the version. You should see a semver string, not an error about a missing command.

$ spritely --version
1.8.2

If the version command is not found, confirm your PATH includes npm's global bin directory. On Unix systems that is often ~/.local/bin or a version-manager shim; re-open the terminal after changing PATH.

Step 2: Authenticate

Log in so deploys are tied to your organization. The command opens your default browser for OAuth. After you approve, the CLI stores a short-lived refresh token in your user config directory and prints a success line in the terminal.

$ spritely login
Opening browser for authentication...
Logged in as you@yourdomain.com

If you are on a headless server, set SPRITELY_DEVICE_CODE=1 first; the CLI will print a URL and code instead of launching a window. For local development, the browser flow is usually enough.

Tokens are stored per user, not inside the repository, so committing your project to Git does not leak credentials. Run spritely logout on shared machines when you are done, and spritely whoami any time you need to confirm the active account.

Step 3: Initialize a project

Create a new directory with a starter schema. The name you pass becomes the default app slug unless you override it later.

$ spritely init my-clinic
Created my-clinic/
  schema.yaml
  .spritely/config.json

The generated tree is intentionally small. schema.yaml is the source of truth for entities, PHI flags, and roles. .spritely/config.json stores local metadata such as the last environment you deployed to; it is safe to commit if your team shares the same defaults, or you can gitignore it and rely on flags.

You can rename the top-level directory without breaking deploys as long as app.slug stays unique in your org. Keep the schema at the repository root unless you pass --schema to point at a different file in CI.

Change into the folder before editing or deploying:

$ cd my-clinic

Step 4: Define your schema

Replace the starter file with a minimal but realistic clinic model: one patient resource, PHI on direct identifiers and clinical text, and two roles. Providers see full charts; front desk staff can schedule and update demographics but you can tighten that later in the same file.

version: 1

app:
  name: "My Clinic"
  slug: my-clinic

resources:
  patient:
    label: "Patient"
    fields:
      mrn:
        type: string
        phi: true
      full_name:
        type: string
        phi: true
      dob:
        type: date
        phi: true
      phone:
        type: string
        phi: true
      email:
        type: string
        phi: true
      chief_complaint:
        type: text
        phi: true
      chart_notes:
        type: text
        phi: true

roles:
  provider:
    label: "Provider"
    permissions:
      patient: [read, write, export]
  front_desk:
    label: "Front desk"
    permissions:
      patient: [read, write]

Every field marked phi: true is encrypted at rest with per-tenant keys. Roles map to built-in policies: export gates bulk download for compliance reporting. If validation fails, the CLI prints a line number; fix YAML indentation first, then re-run spritely validate if you want a fast check without deploying.

The example keeps one resource to stay readable. Production apps usually add appointments, insurance cards, and documents; the same resources map scales by adding blocks and tightening permissions per role. Start small, deploy, then expand the schema when your team agrees on the data model.

Step 5: Deploy

From the project root, deploy pushes schema, keys, and generated UI to Spritely's managed environment. Expect roughly ninety seconds on a warm account; first deploy can take a bit longer while DNS for your subdomain propagates.

$ spritely deploy
Validating schema... OK
Provisioning encryption keys... OK
Configuring access control (2 roles)... OK
Generating application... OK
Deploying to production... OK

App URL: https://my-clinic.spritely.health
Build time: 1m 31s

The slug in schema.yaml becomes the subdomain. If the name is taken, the CLI stops before mutating infrastructure and suggests an alternate slug. Re-deploys are incremental: unchanged fields skip unnecessary key rotation, which keeps subsequent pushes fast.

Use --dry-run to print the planned changes when you are editing roles or PHI flags and want confidence before touching production. Dry runs still hit validation and permission checks; they skip the network round trip that publishes the build.

Step 6: Verify

Open the printed URL, complete the first-time org setup if prompted, and sign in with a test user assigned to provider or front_desk. Create a patient record and reload the page: values should render normally in the UI while storage remains ciphertext server-side. Open another browser profile with a user that lacks access; reads should fail with a consistent access-denied state, which confirms authorization is enforced outside your application code.

Check the network tab once: API responses should be JSON with stable field names, and you should not see raw key material or decrypted payloads in logs you did not explicitly enable. Session cookies are HTTP-only and scoped to your subdomain. After fifteen minutes of inactivity, expect to re-authenticate, which exercises the idle timeout path without waiting for a full workday.

Audit trails are on by default. Stream recent access events to your terminal with:

$ spritely logs --tail
14:02:01Z  READ   patient/8f3c...  user:jordan@clinic.example  role:provider
14:02:04Z  WRITE  patient/8f3c...  user:alex@clinic.example   role:front_desk

Those lines are immutable once written; they are what you would export during an internal review or regulator inquiry.

What you get

Without writing a custom backend, you inherit AES-256 field-level encryption for PHI columns, role-based access aligned to your YAML, append-only audit logging with actor and resource identifiers, a fifteen-minute idle session timeout, and TLS on every hop. Those defaults map to common HIPAA administrative and technical safeguards; you still own policies, BAAs, and clinical workflows, but the baseline controls are live the moment the deploy finishes.

Encryption keys are managed for you: rotation schedules and access boundaries stay on the platform side, while your schema continues to declare which fields require protection. Audit entries include enough context to reconstruct who touched which record without storing unnecessary payload data. Together, that reduces the custom code you must review before production and keeps the blast radius small when roles change.

What's next

Go deeper on modeling: read Defining Your Healthcare Data Schema in YAML for field types, relationships, and validation rules beyond this minimal example. For how encryption, sessions, and audit retention fit together without custom compliance engineering, see Zero Compliance Engineering: How Spritely Eliminates HIPAA Busywork.