Yosemite Crew: a self-hosted PIMS for veterinary clinics, read from the repository
Open-source operating system for animal health
At a glance
- What is it?
- Yosemite Crew is a TypeScript practice information management system for animal health, shipped as a web platform, a React Native mobile app and a desktop client. The README states the intent clearly, but the licence file and the deployment path are the two things an adopter has to resolve before anything else.
- Who is it for?
- Adopt Yosemite Crew if you run a small animal practice that wants to own its records and has someone who can read a Dockerfile, and if you are willing to pin to a beta tag rather than main. Do not adopt it if you need a signed support contract, a certified data-processing agreement, or a product where the licence terms are already settled.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Yosemite Crew is aimed at
Veterinary practices run on practice information management systems, usually shortened to PIMS. The repository's own topics list both pims and pms, alongside practice-management-system, veterinary-software and self-hosted. That combination tells you who this is for. A clinic that wants its appointment book, patient records and client history in software it controls, rather than in a vendor's tenancy, has had few options that are both open source and built specifically for animal health rather than adapted from human medicine. The README frames the project as an operating system for animal health and describes it as a free, fully customizable Practice Information Management System. The second half of that sentence is the claim worth testing: customizable by whom, and at what cost in maintenance. The repository is public, the default branch is main, and the last push recorded is 2026-09-10, so this is an active codebase rather than an abandoned one. What the README does not do is name a target clinic size. Nothing in the supplied material says whether this is meant for a single-vet practice or a multi-site hospital group, and that ambiguity matters when you are judging whether the data model will fit you.
Four clients, one codebase, and what the release tags imply
The SonarCloud table in the README splits the project into four measured components: Backend, Platform (Frontend), Mobile App, and Desktop. That is not a single application with a mobile view. It is a backend plus three separate client surfaces, which is a large amount of code to keep in step. The release list supports that reading. Three tags appear within minutes of each other on 2026-08-31: Yosemite Crew PIMS Desktop v0.1.0-beta.5, pims-v2.4.0-beta, and mobile-v1.6.2. Different version numbers, different prefixes, released as a batch. The desktop client is at 0.1.0 while the PIMS platform is at 2.4.0, so the desktop surface is plainly the youngest. If your clinic works from a front desk and a phone, you are depending on two artefacts with very different maturity. The mobile client is built with React Native, which the repository topics confirm. The primary language across the repository is TypeScript. For a team that already writes TypeScript, that is a real advantage: one language across backend, web, mobile and desktop means a single hiring profile and shared types. For a team that does not, it means learning the whole stack before you can change anything.
Self-hosting: Docker is named, the compose file is not shown here
The repository carries a docker topic, and the README's framing is explicitly self-hosted. That is the extent of what the supplied material establishes. There is no installation section in the excerpt, no documented environment variables, no database choice, no migration command. I am not going to invent a docker compose up line for a project I have not run. What can be said is structural: a backend plus three clients plus a self-hosting story usually means at minimum a database, an API service, and a web front end behind a reverse proxy, with the mobile and desktop clients pointed at your own API base URL. The variables that configure that base URL are the first thing to look for in the repository, because they determine whether the mobile and desktop builds can be aimed at a clinic's own server or are compiled against a fixed host. Until you have read that configuration, the phrase self-hosted is a direction, not a verified property of every client in the suite.
The licence is the first thing to resolve, not the last
GitHub reports the licence as NOASSERTION. That means the platform could not match the licence file to a known template, which happens with custom or modified terms. The README links to a licence file in the repository root, and the badge next to that link is labelled simply License. So a licence file exists. What it says is not in the material supplied to me, and I will not guess between an open licence, a source-available licence with restrictions on commercial hosting, or something in between. This is not a formality for a clinical system. A practice storing client contact details and patient treatment history is handling personal and medical data, and the licence governs what you may do with the software, not what you may do with the data. Those are separate questions and the second one is not answered by any file in this repository. Read the licence file before you read the deployment docs. If the terms restrict commercial use or require you to publish modifications, that changes the decision more than any feature list will.
Where this is the wrong tool
A clinic with no one on staff who is comfortable with containers, environment files and database backups should not self-host this, regardless of how good the feature set is. The project gives you the software; it does not give you the operations. There is no mention in the supplied material of a managed hosting option, a migration path from an existing PIMS, or a data export format. That last gap is the one I would press on hardest. Moving years of patient records out of a commercial system into a self-hosted one is the single largest cost in any adoption, and nothing here indicates the project has built importers for the common formats. There is also the beta status. Two of the three most recent releases carry beta in the tag, and the desktop client is at 0.1.0. Running beta software for appointment scheduling is a choice a practice can make deliberately, but it should be made deliberately. A clinic that needs a vendor to answer the phone at 8am on a Saturday is not the audience for this repository today.
What it is actually competing with
The realistic alternative is not another open-source veterinary PIMS, because there are very few. It is a commercial cloud PIMS on a per-seat subscription. The difference in approach is not features, it is who holds the database and who is accountable when it goes down. A commercial cloud product bundles hosting, backups, upgrades and support into one invoice and one phone number. Yosemite Crew inverts that: you get the source, the four components and the freedom to modify them, and you take on the server, the backups and the upgrade treadmill yourself. For a practice with an IT function or a friendly managed service provider, that trade can be favourable, particularly over a multi-year horizon where subscription costs compound. For a practice without one, the subscription is buying something real. There is a middle position worth noting: a practice could run Yosemite Crew for a non-critical function first, such as a mobile client for field visits, while leaving the core records where they are. Nothing in the material says the project supports partial adoption, but the separation into four clients suggests it might.
Maintenance cost and the upgrade path
Three release tags on one day in August 2026, then a push to main in September. That cadence is the maintenance story in miniature. If the backend, web platform, mobile app and desktop client are versioned separately, as the tags indicate, then an upgrade is not one action. You are tracking pims-v2.x, mobile-v1.x and a desktop client still in 0.1.0-beta, and you have to decide whether to move all three together or let them drift. Drift is where self-hosted clinical software gets painful: a mobile client that speaks an older API contract against a newer backend. The repository does run static analysis across all four components, which the SonarCloud table makes visible, so there is at least a quality gate in the project's own workflow. That is a signal about the maintainers' process, not a guarantee about your deployment. Budget for reading release notes before every upgrade, and for a staging instance that is not the machine your front desk uses. If that sentence sounds like too much work, the commercial alternative is priced for exactly that reluctance.
Editorial conclusion
Adopt Yosemite Crew if you run a small animal practice that wants to own its records and has someone who can read a Dockerfile, and if you are willing to pin to a beta tag rather than main. Do not adopt it if you need a signed support contract, a certified data-processing agreement, or a product where the licence terms are already settled. Verify two things first: the contents of the licence file the README links to, and whether the desktop and mobile clients are at the same feature level as the web platform, since the release tags suggest they move on separate schedules.
Community notes