Outsiders Village: Infrastructure, Portability, and Self-Hosting
Content updated: September 21, 2026 at 5:50 PM MDT
Purpose
The technical infrastructure for Outsiders Village should support village life without becoming a source of centralized control. The goal is to make it possible for people to use shared tools, create their own villages, and communicate without requiring the person who runs the servers to manage the relationships happening inside them.
The infrastructure should also be portable. If the person or group running one instance becomes controlling, unavailable, unreliable, or simply stops being a good fit, villagers should still have access to the open-source software and documentation needed to create another instance.
Contents
• The running service is not the village
• Villages should be able to manage their own activity
• Public and village-specific events
• Portability is a protection against capture
• Future technical documentation
• This document is exploratory
Open source by design
The software and deployment infrastructure created for Outsiders Village should be open source whenever practical.
The goal is for another technically capable person to be able to reproduce the system without needing permission, private knowledge, or continued access to the original operator.
Documentation should eventually explain the steps needed to recreate the infrastructure, including services such as Railway, Cloudflare, Meetup integration, databases, domains, deployment, backups, scheduled jobs, and other required services.
Someone should be able to take the code, modify it, host it themselves, and build a different version that better fits their own village.
The running service is not the village
The village website may provide useful infrastructure, but the website is not Outsiders Village itself.
The people and relationships are the village. The software is a tool.
The person maintaining the infrastructure may need technical administrative access to keep the system functioning, but that access should not automatically make them the leader, moderator, owner, or decision-maker for the villages using it.
Villages should be able to manage their own activity
The running website should eventually make it possible for villagers to create and manage smaller villages and gatherings without requiring infrastructure administrators to manage ordinary village life.
The exact design will evolve through use.
Possible functionality may include:
- creating smaller villages or groups
- creating events
- deciding whether an event or village is public, broadly visible, or limited to particular people
- managing membership
- removing people from a particular village when necessary
- communicating through forums or other shared spaces
- assigning practical event roles such as host or facilitator
- tracking attendance when useful
- managing village-specific information such as descriptions, settings, shared resources, and other content
Note that just because a person runs the website and infrastructure tools, that does not automatically mean that they run the villages that use it.
Public and village-specific events
Some events may be appropriate for broad discovery through services such as Meetup. Others may be intended only for the members of a particular small village.
The infrastructure should eventually support both.
Public or broadly open events could be published or synchronized to Meetup when useful. Smaller village-specific gatherings could remain within outsidersvillage.org so that the village itself can decide who sees them and who may attend.
Trust and technical power
Running infrastructure creates real power. The operator may have access to servers, databases, logs, backups, configuration, and other information that ordinary users do not.
That power should be acknowledged rather than hidden.
Technical access should be limited to what is needed to operate the system, and privacy and security should be built into the infrastructure wherever practical. The operator should not use technical access to control relationships, punish disagreement, or interfere in village decisions simply because they have administrative access.
Portability is a protection against capture
No technical system can completely eliminate the need for trust. One of the strongest protections against centralized control is making sure people can leave.
If an infrastructure operator, organization, or village no longer reflects someone's values or needs, the software and documentation should make it possible for people to build something different rather than remaining trapped because one person controls the tools.
Leaving is not betrayal or failure. Forking the software, creating another instance, or starting another village can be a legitimate response to incompatibility, concentrated power, or a different vision.
The goal is not to create one permanent Outsiders Village platform that everyone must use. The goal is to build useful infrastructure that can be copied, changed, abandoned, replaced, and rebuilt.
Relationship to paid work
Open source does not require all labor around the software to be unpaid.
The code and deployment documentation can remain open while individuals or businesses offer paid services such as hosting, setup, customization, integrations, training, maintenance, support, migration, or development.
No village should have to purchase those services in order to use the underlying open-source software. Paying someone for technical labor should not buy authority over Village values or the relationships of the people using the system.
Future technical documentation
A separate technical runbook should eventually document, step by step, how to recreate a working Outsiders Village deployment.
That documentation may include:
- source-code repositories and required configuration
- Railway projects, services, databases, environment variables, and deployment
- Cloudflare DNS, domains, security, and related configuration
- Meetup application or integration setup when used
- scheduled jobs and synchronization
- email or notification infrastructure
- backups and restoration
- migration and export procedures
- privacy and security considerations
- and how to operate a completely independent instance
The test for the documentation should be simple: another technically capable person should be able to create their own working system without needing Robee to do it for them.
This document is exploratory
These ideas describe the direction of the infrastructure, not a finished architecture. The software, hosting model, governance tools, and integrations should change as real villagers use them and reveal what is actually useful.