Getting started with Pharmacy
Install the current source, configure PostgreSQL and sessions, review migrations, run checks, and complete synthetic onboarding.
Requirements
Current package.json requires Node.js 20 or later. The database-backed application uses PostgreSQL, Prisma, Keystone, Next.js, and a long random session secret.
Install the locked dependency tree from the repository root:
npm ciCreate a local environment file for a database you are authorized to change:
DATABASE_URL=postgresql://user:password@127.0.0.1:5432/openfront_pharmacy
SESSION_SECRET=replace-with-a-long-random-secret
PUBLIC_SIGNUPS_ALLOWED=falseOptional integrations have additional variables documented in Integrations and boundaries. Keep provider secrets outside source control.
Review and apply migrations
The current working source contains eleven migration directories: seven inherited starter migrations plus Pharmacy foundation, behavioral-depth, tenant-identity, and required-relationship changes. Review the complete history and test both an empty database and the actual upgrade path before applying it to any retained data.
npm run keystone:build
npm run migrateBoth npm run dev and npm run build invoke npm run migrate. They can change the database referenced by DATABASE_URL. Do not point either command at an uncontrolled, shared, or production database. Separate migration deployment from application build before adopting an immutable-image release process.
Start the local application only after migration review:
npm run devThe storefront is at /, the operator dashboard at /dashboard, and GraphQL at /api/graphql. Do not use schema push or a destructive reset as a substitute for reviewed migrations.
Create the first operator
The shared dashboard initialization flow creates the first authenticated user. Keep public signup disabled unless a separate enrollment and identity process is designed. Grant only the organization, location, catalog, inventory, recall, patient, prescription, dispensing, order, payment, integration, onboarding, audit, and consequential-approval permissions required by the person's actual job.
A role with dashboard access is not automatically a pharmacist. Pharmacist credential and scope verification happen outside this repository and must be enforced by the deploying organization.
Pharmacy onboarding
runPharmacyOnboarding requires the onboarding permission and creates synthetic evaluation data for an organization, location, drug references, products, lots, a patient/prescriber/prescription path, provider placeholders, and onboarding state. It can create a development-only demo payment provider only when both conditions are true:
NODE_ENV=development
ALLOW_DEMO_PAYMENTS=truesetPharmacyOnboardingStatus only requires a signed-in user and changes that user's status; it does not authorize seed execution or pharmacist work. The seeded eRx, wholesaler, insurance, and tax provider records are explicitly unconfigured. Seeded prescriptions, patients, drug references, lots, prices, and provider records are synthetic examples, not validated operating data. Re-run onboarding on an isolated database to check idempotency, then remove or clearly segregate evaluation records before any real deployment.
Source checks
Current source defines these checks:
npm test
npm run typecheck
npm run keystone:build
npm run buildThe repository's lint script currently delegates to next lint; verify that command against the installed Next.js version before treating lint as a release gate. A passing build, test, browser render, or HTTP response proves only the behavior exercised by that check. It does not certify licensure, legal compliance, clinical safety, patient privacy, provider acceptance, physical inventory, or lawful dispensing.
Deployment sequence
- Define the licensed organization, authorized locations, accountable pharmacist roles, policies, jurisdictions, providers, retention rules, and incident owners.
- Review the dependency tree and resolve security findings under an owner-approved framework baseline.
- Back up the target database and test restoration.
- Review and deploy migrations as a separate controlled step.
- Configure stable session, SMTP, payment, storage, and other secrets through a managed secret system.
- Configure only adapters that have contract, credential, webhook, retry, reconciliation, and failure tests.
- Run cross-organization, cross-location, patient-privacy, permission, lifecycle, concurrency, idempotency, duplicate-callback, and rollback tests against the exact release snapshot.
- Exercise prescription, dispensing, lot, recall, cold-chain, OTC checkout, payment, fulfillment, audit, and recovery workflows with synthetic data and accountable human reviewers.
- Stage rollout with monitoring, backups, incident response, provider escalation, rollback, and downtime procedures.
Use Current limitations as a minimum pre-deployment review, not a complete jurisdiction-specific checklist.