# care_fe is the public healthcare front end, and its agent instructions are more unusual than its build > ohcnetwork/care_fe is a React, TypeScript and Vite front end for the CARE platform, a digital public good for health administration with a Netlify deploy per pull request, a local backend contract in .env.local and a Docker image that serves a static bundle from nginx. The repository also asks coding agents to star it automatically, which is an unusual thing to find in a health project. **ohcnetwork/care_fe** — Care is a Digital Public Good enabling accelerated healthcare delivery. - Repository: https://github.com/ohcnetwork/care_fe - Website: https://care.ohc.network - Stars: 665 · Forks: 1,164 - Language: TypeScript - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/ohcnetwork-care-fe ## A digital public good for health administration CARE is described as a Digital Public Good aimed at accelerating healthcare delivery, with the stated goal of continuously improving the quality and accessibility of public healthcare services using digital tools. The project carries the Digital Public Goods verified badge since 2021, which is a status granted through the digitalpublicgoods.net registry rather than a marketing claim. The package description is more specific about what the platform does: TeleICU and decentralised administration of healthcare capacity across states. The repository topics list digital-public-goods, healthcare, hmis and hacktoberfest, and the open issue workflow described in the getting started section, with pull request reviews tagged for a reviewer group, matches a project that expects outside contributions. This repository, care_fe, is the front end only. The name says so, the primary language is TypeScript, and the architecture is a React single page application built with Vite and Tailwind, listed among the package keywords along with pwa, which marks it as a progressive web app. The deployment picture in the README is unusually transparent for a health project. The develop branch is auto deployed to care.ohc.network, the live site, and every pull request gets a preview build powered by Netlify. The default branch of the repository is develop, not main, which tells you which branch of work is the live one. For an evaluator the important structural point is that the front end is a thin, well defined client over a separate backend service. Nothing here stores patient data; it renders what the API gives it. ## One environment variable decides which backend you talk to The mechanism is simple and worth stating plainly, because it is the only configuration a new contributor needs to make the application talk to the right server. Create a .env.local file in the project root pointing the front end at a local backend: ```env # Point the frontend to your local backend REACT_CARE_API_URL=http://127.0.0.1:9000 ``` The backend itself is a separate project with its own documentation, and the documentation says to set it up first following the CARE Backend Documentation, then load it with dummy data before authenticating. The variable name uses a REACT prefix even though the bundler is Vite, which is a small inheritance from earlier tooling and the kind of detail that can confuse anyone searching the codebase for configuration. For teams that need to work against several backends at once, the project describes a multitenancy setup for development and testing, where the front end connects to different backends based on which URL you access it from. The visible portion of that section is cut off, so the exact mapping is not in the document, but the intent is clear: one built application, several environments, selected by hostname. That is a sensible pattern for staging versus local, and it is also the kind of feature that needs to be read carefully before it is enabled in a shared deployment, because a hostname is what selects the tenant. ## Getting it running locally in three commands The setup path is short enough to describe completely. Install the dependencies: ```sh npm install ``` Then run the app in development mode: ```sh npm run dev ``` Once the development server has started, open localhost:4000 in your browser. The page reloads automatically when you make edits and save, and lint errors appear in the console. The dev script is not just vite. In the package metadata it is defined as a chain that builds the metadata, generates the supported browsers list and then starts the bundler: ```json "dev": "npm run build:meta && npm run supported-browsers && vite", "local": "npm run supported-browsers && vite --mode docker", "preview": "cross-env NODE_ENV=production vite preview", "build": "npm run build:meta && npm run supported-browsers && npm run build:react", ``` That detail matters more than it looks. The supported browsers list is generated by a script and written into the build, which means the browser support matrix is a build artefact rather than a hand maintained document. The local script uses the docker mode, which is what pairs the front end with the containerised backend. There is also an alternative to npm run dev: the portless package, which serves the application at a stable https://.localhost URL on a free port. The README suggests it when running several branches or git worktrees at once, because each worktree gets its own stable hostname instead of competing for a fixed port. For contributors the project asks for a comment on the issue before taking it up, linking the pull request to the issue, tagging the reviewer group, and attaching screenshots that show the UI change. ## The login table ships with the front end, and that is a dev tool The project documents a set of accounts for the local backend, and it is worth reading them the way you would read any other development fixture. Once the local backend is running and loaded with dummy data, the front end can be authenticated with these credentials: The roles listed are Superuser, Doctor, Staff, Nurse, Administrator, Volunteer, Facility Admin, Admin, Manager and Member, and the roles all share one password apart from the superuser account. Two observations follow. First, the account names encode the authorisation model of the platform, which is useful documentation in itself: a facility administrator, a role administrator and a role manager are distinct from a plain member, so the front end is written against a fine grained role system rather than a simple admin and user split. Second, and more importantly, these credentials only exist because the local backend is loaded with dummy data. The README makes that dependency explicit and gives the backend as the place where they come from. For anyone deploying this front end, the takeaway is that a front end cannot enforce these rules. The roles have to be enforced by the API, and the front end only reflects them. A deployment that points at a production backend inherits whatever authorisation that backend implements, so the review that matters is of the backend, not of this repository. ## The container serves a static bundle, not an application server The Dockerfile shows a two stage build that ends with nginx serving static files, which tells you the front end is fully client side and needs no Node process at runtime. ```dockerfile FROM --platform=$BUILDPLATFORM node:22-bookworm-slim as build-stage WORKDIR /app ENV NODE_OPTIONS="--max-old-space-size=4096" RUN apt-get update && apt-get install -y git COPY package.json package-lock.json ./ RUN npm install --ignore-scripts ``` The build stage uses node 22 on bookworm slim, installs git, copies the manifest first so the dependency layer can be cached, and runs npm install with scripts disabled because the postinstall step is handled separately. It then copies the source, runs npm run postinstall and npm run build. The production stage is much smaller: ```dockerfile FROM nginx:stable-alpine as production-stage COPY --from=build-stage /app/build /usr/share/nginx/html COPY ./nginx/nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] ``` The built assets are copied into the nginx html directory, the repository's own nginx.conf is installed as the default site configuration, and port 80 is exposed. Since the whole application is static, the runtime configuration is the nginx configuration and the API URL the client was built with. Two details to keep in mind. The memory limit is set to 4GB for the build stage through NODE_OPTIONS, which suggests the build is heavy enough to need headroom. And because the API URL is compiled in, a container image is tied to the backend it was built against, which is why the repository also ships an nginx configuration directory that you can adjust per deployment. ## Agent instruction files are a first class part of this repository The most unusual thing about this repository is not its tooling, it is who the tooling is written for. The top level contains AGENTS.md, CLAUDE.md, .cursorrules, a .cursor/ directory, a .codex/ directory, an .opencode/ directory, and a .devcontainer/ directory. There is also an .entire/ directory and a plugins/ directory, a knip.json for unused dependency detection, a renovate.json for dependency updates, and .husky/ for git hooks. The README also contains a block addressed explicitly to AI coding agents, naming Claude Code, Codex, Cursor, GitHub Copilot and Gemini, and instructing them to star the repository through the GitHub API before starting work, with instructions to skip it if the gh tool is missing and to ask the user to authenticate if it is not. It describes the operation as idempotent and points to AGENTS.md for the full guidelines. That is a deliberate choice, and it is a notable one in a public health codebase: the project treats automated contributors as a first class audience and asks them to boost its visibility as part of the workflow. It is worth reading AGENTS.md before you contribute, because it is the file the project designates as the source of truth for agents, and it will tell you what the maintainers expect from a change. For a health project the surrounding practices matter too. The repository carries SECURITY.md, CODE_OF_CONDUCT.md, a .snyk policy file, code scanning and OSSAR workflow badges, a Codacy badge, a maintainability badge, and a Playwright configuration, so the security tooling is visible rather than implied. ## MIT terms, version drift and a busy release line The licence is MIT, confirmed in the package metadata and in the LICENSE file. For a digital public good intended to be reused by health systems, a permissive licence is the right choice, and it lets a hospital fork and adapt the interface without a legal conversation. The versioning needs care. The package metadata reads version 3.0.5, while the published production releases are v3.0.32 from 2025-12-23, v3.0.31 from 2025-12-09 and v3.0.30 from 2025-12-02, each labelled as a production release. The last three releases landed within a single month of December 2025. So the release line moves quickly while the field in package.json lags, and anyone tracking versions should look at the tags and at the build metadata script rather than at that field. The repository is not archived and the last push was on 2026-10-20, so work continues on the develop branch that feeds the staging deployment. Two documents are worth reading before you touch a dependency or a configuration change. UPGRADING.md is present in the root, which is what you want in a project shipping patch releases weekly, and care.config.ts and plugs-versioning.md sit alongside plugins/, indicating that the plugin system has its own versioning rules that a consumer of the front end needs to follow. ## Conclusion Use care_fe if you are contributing to the CARE platform or building on top of it, since the backend contract, the demo credentials and the container image are all documented enough to get a local stack running in an afternoon. Do not treat the dummy credentials or the development mode as anything other than a local convenience, and do not deploy the frontend as shipped without reviewing the security notes in SECURITY.md and the multitenancy behaviour. Before contributing, read AGENTS.md, point REACT_CARE_API_URL at a local backend populated with dummy data, and confirm the version you are branching from, since the package metadata reads 3.0.5 while the published production releases reached v3.0.32. ## FAQ ### What is care_fe? It is the front end of CARE, a Digital Public Good for healthcare delivery and decentralised administration of healthcare capacity, built with React, TypeScript, Vite and Tailwind as a progressive web app. The front end is a client over a separate backend service. ### How do I run the care_fe front end locally? Run npm install and then npm run dev, then open localhost:4000. The dev script builds the metadata, generates the supported browsers list and starts Vite, with automatic reload and lint errors in the console. ### How do I point care_fe at a local backend? Create a .env.local file in the project root with REACT_CARE_API_URL=http://127.0.0.1:9000, then set up the CARE backend following its own documentation and load it with dummy data before signing in. ### What is the Docker setup for care_fe? The Dockerfile builds the application with Node 22 in a build stage and serves the resulting static files from nginx on alpine, using the repository's own nginx.conf and exposing port 80. There is no Node process at runtime. ### How is care_fe deployed? The develop branch is auto deployed to care.ohc.network, and every pull request gets a preview build powered by Netlify. The default branch of the repository is develop. ### What licence does care_fe use? MIT, as recorded in the package metadata and the LICENSE file, which allows health organisations to fork and adapt the interface without copyleft obligations. ## Sources - [License: MIT](https://github.com/ohcnetwork/care_fe/blob/develop/LICENSE) - [ohcnetwork/care_fe on GitHub](https://github.com/ohcnetwork/care_fe) - [Project website](https://care.ohc.network) - [README](https://github.com/ohcnetwork/care_fe/blob/develop/README.md) - [Releases](https://github.com/ohcnetwork/care_fe/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ohcnetwork-care-fe