Some Open Source projects are more than a repository. They also run a hosted service: a public demo, a free community instance, an API endpoint, or a tool that non-technical users rely on every day.
When that hosted service needs to end, the work is different from archiving code. You are not only closing issues or marking a repo read-only. You are helping real people avoid surprise, data loss, broken workflows, and confusion.
This matters for public benefit software. A free tool for education, accessibility, security, or civic work may be used by people who do not have an easy paid replacement. Ending the service carefully is one way Open Source developers can keep serving people, even when they cannot keep running the infrastructure forever.
Why This Stage Matters
A project can be healthy as code but unsustainable as a hosted service. Hosting costs money. Operations take time. Security updates never stop. Abuse handling, backups, account support, and uptime can become too much for a small team or solo maintainer.
Sunsetting the hosted part does not mean the whole project failed. It means you are being honest about what you can responsibly support.
The goal is simple: close the service in a way that protects users, preserves the Open Source value, and leaves a clear path for anyone who wants to self-host, fork, or learn from the work.
Step 1: Separate the Codebase from the Hosted Service
Start by naming exactly what is ending.
- The hosted service: the live website, public instance, API, database, email system, file storage, or background workers you operate.
- The Open Source project: the repository, license, documentation, releases, issue history, and community knowledge.
Do not make users guess. A clear distinction reduces panic and helps contributors understand what is still possible.
For example, you might write: “The public instance at app.example.org will shut down on October 1. The source code will remain available under its current license, and the repository will stay readable for self-hosting and forks.”
This is especially important when non-technical users only know the hosted website. They may not understand that “Open Source” and “the service we run” are two different things.
Step 2: Stop New Dependence Before Shutdown
Before you turn anything off, stop making the problem bigger.
- Disable new account creation, or add a clear warning before signup.
- Remove “start using this today” language from the homepage.
- Update onboarding emails, docs, and install guides that point people to the hosted service.
- Add a banner inside the app for logged-in users.
- Pause integrations that encourage new teams to connect their data.
This step is about consent. New users should not invest time setting up a service that is already scheduled to close.
If you run an Open Source tutoring scheduler for community literacy programs, for example, a new volunteer coordinator should not spend a week entering student availability into a service that will disappear next month. Stopping new dependence early is a form of respect.
Step 3: Use a Read-Only Period When Possible
A read-only period gives users time to collect information without creating more data you must preserve or migrate.
Depending on your project, read-only mode might mean:
- Users can log in and view records, but cannot create new ones.
- Reports and exports still work.
- Public pages remain visible, but editing is disabled.
- API write requests return a clear error message.
- Scheduled jobs stop changing user data.
You do not need a perfect read-only system. If the app was not built for it, choose the smallest safe version. For some projects, that may be a database backup plus static HTML exports. For others, it may be disabling forms and write endpoints.
Set a specific window. For example: “The service will become read-only on September 1 and will shut down on October 1.” That gives users two dates to plan around.
Step 4: Protect Accounts, Data, and Secrets
Sunsetting a hosted service includes a security responsibility. A neglected server full of old accounts is not a legacy; it is a risk.
Make a short data plan:
- What user data exists?
- What can users export?
- When will production data be deleted?
- Who has access during the shutdown period?
- What backups exist, and when will they be removed?
- What API keys, tokens, webhooks, or email credentials need to be revoked?
Be careful with promises. Only say what you can actually do. If you can provide a CSV export, say that. If you cannot support custom migrations, say that too.
For public benefit projects, this can affect vulnerable users. An accessibility feedback tool may contain disability-related notes. A civic reporting app may contain location data. A classroom tool may contain student information. Handle shutdown like a security task, not just an operations task.
Step 5: Keep Domains and Project Names Safe
One overlooked part of sunsetting is what happens after the service disappears.
If a domain expires, someone else may buy it and impersonate the old project. If a package name is abandoned without explanation, users may install the wrong thing. If an API endpoint starts returning unrelated content, integrations may fail in strange ways.
Where possible:
- Keep the domain long enough to show a shutdown page or redirect to the repository.
- Leave a simple static page that explains the project status.
- Update package registry descriptions with a maintenance note.
- Remove or rotate credentials connected to the old domain.
- Make sure documentation does not point users to dead or unsafe URLs.
You may not be able to keep every asset forever. But even a small static page is better than a silent disappearance.
Step 6: Help Self-Hosters Understand What Still Works
If the code remains useful, make the boundary clear for future maintainers and self-hosters.
Add a short section to the README or docs that says:
- the hosted service has ended;
- the code is still available under the project license;
- which version was last used in production;
- which external services are required;
- which parts are known to be stale or risky;
- whether issues and pull requests are still reviewed.
This helps someone decide whether to fork, deploy internally, or reuse parts of the project. It also prevents a common misunderstanding: users may think “the website is down” means “the software is gone.”
Open Source legacy is not only about keeping files online. It is about leaving enough context for the next person to make a safe decision.
Step 7: Close the Service with a Final Checklist
Before the shutdown date, run through a practical checklist.
- Shutdown notice is visible on the website, inside the app, and in the repository.
- New signups or new data creation are disabled.
- Exports or final access instructions have been tested.
- Admin access is limited to only the people who need it.
- Backups, logs, and stored files have a deletion plan.
- API clients receive a clear response instead of failing silently.
- Domains, package pages, and docs point to the final status page.
- The repository explains whether forks and self-hosting are welcome.
You do not need to make the ending perfect. You need to make it understandable, safe, and honest.
That approach fits the mission of building sustainable Open Source software that benefits all people. Sustainability sometimes means continuing. Sometimes it means handing off. And sometimes it means ending the hosted service without leaving users behind.
TL;DR
When you sunset a hosted Open Source service, separate the live service from the codebase. Stop new users from depending on it, provide a read-only period if possible, protect data and credentials, keep domains and package names safe, and document what still works for self-hosters.
Ending a service well is part of responsible Open Source. It protects users, preserves trust, and leaves useful software behind for the people who may need it next.