What This Browser 3D Virtual World Depends On — and What It Does Not: a Checklist That Decides How Far You Can Move It
self-hosted 3D virtual worldwhat server does a 3D virtual world needdoes a 3D scene server need a GPUbrowser 3D tech stackthree.js project deploymentNode and PostgreSQL deploymentself-hosted 3Dintranet 3D scene deploymentportable 3D systemsource-available
When people choose a system, they look at the feature list: can it do multiplayer, can I swap models, can it connect to an AI. All worth checking.
But what decides whether a system is still maintainable two years from now is usually not the feature list — it is the dependency list: what it is tied to, which things you have to ask someone's permission to change, which subscriptions you have to keep renewing.
This article lays out the dependency relationships of Genesis (创世Genesis ／ 创世虚拟世界CRM系统 — the same self-hosted 3D virtual world product under both names): what it needs, what it does not, and what each "does not" is worth in practice. Three things it covers:
- How many things it actually takes to install
- What it is not tied to
- What those "not tied to" items turn into in daily use — and where the boundary is
Licence first: the source is available (source-available), running it locally costs nothing; going online, commercial use or federation requires a subscription license. The binding terms are in the repository LICENSE / EULA.
1. Why the dependency list matters more than the feature list
The feature list answers "what can it do now". The dependency list answers "can it still do it later".
One practical test: how many accounts, approvals and vendors are needed to install it on a machine where you have no special privileges? A solution that needs three cloud services, one platform account and one quota application is something you cannot move, however complete its features.
The image above shows this world open in a desktop browser. Note one thing: the picture is computed in the visitor's browser; the server is not drawing it. That single fact is the source of most of the "does not depend on" items below.
2. What it depends on: two pieces of infrastructure
| Dependency | What it is specifically | Can it be skipped |
|---|---|---|
| A JavaScript runtime | A Node-class runtime running the server process | No. This is the server itself |
| A relational database | PostgreSQL | No. World data, users and configuration live here |
| Static assets and bundling | Build output loaded by the browser; bundling uses a public build tool | No, but it is a build-time concern, not a running service |
| A browser | A modern browser with WebGL2 | No. This is the client, and where rendering happens |
| Network and domain | A domain if it is to be reachable publicly; mainland China servers also need filing | Internal use does not require public access |
What this table means: two long-running services, and no third. One runtime process, one database. Not "two plus a pile of middleware" — two.
3. What it does not depend on
| Not a dependency | Why it matters |
|---|---|
| A specific cloud vendor | No managed service or vendor-specific SDK is required. Any machine that runs Node and PostgreSQL works |
| A GPU server | Rendering happens in the visitor's browser; the server handles logic, state and synchronisation |
| Long-running message queues, cache clusters, container orchestration | Not a prerequisite for running this |
| A platform account | No third-party app registration or API key is needed to get it running |
| A proprietary build chain or private package source | Dependencies come from public package managers |
| A desktop client or browser extension | Visitors open an address and they are in |
One sentence to prevent misreading: "does not depend on" describes running prerequisites, not "nothing to look after". Section 5 is about the work that still needs a person.
The image above is the same world opened in a phone browser. It is here to give weight to the word "client": rendering happens on the visitor's device, so the server needs no GPU — and it also means how strong the visitor's device is decides how good the picture looks. That is two sides of the same fact.
4. What each "does not depend on" turns into
The list itself is useless; its value is what it buys back. Item by item.
First, you can move it. Change hosting providers, change data centres, move from cloud to a machine in the office — these are configuration and data migration tasks, not rewrites. Freedom to move comes from not being bound to managed services. A system built on one vendor's proprietary database service may be more capable, but its data lives inside someone else's engine.
Second, it can live on an intranet. Rendering happens in the browser; the server needs one HTTP connection. That means it runs in a server room with no internet access — for intranet deployment, the hard part is approval, not technique.
Third, the server needs no graphics card. This one is often misunderstood. People assume "3D means a GPU server" and budget for one. The server does not draw; it computes positions, state, and who is looking at what. Not budgeting for a GPU changes the holding-cost structure of the whole thing — though I will not quote a figure, because data centres and bandwidth vary far too much.
Fourth, the maintenance floor is low. Two long-running services means backup, monitoring and upgrades apply to two objects, not ten. A smaller system is one you still dare to touch two years later.
Fifth, AI coding tools can read it. Dependencies coming from public package managers means AI has seen these packages and knows how they are used. If a system is built on a bespoke DSL or a private in-house framework, AI's help degrades noticeably — it has nothing to compare against. This is why "public dependencies" became an extra benefit in the AI era, something nobody considered when the stack was chosen.
5. "Does not depend on" is not the same as no threshold: six jobs still need a person
This section matters more than the list above, because it is closer to the real experience.
- The runtime version has to be right. Node version differences break dependency installation outright. This cannot be delegated.
- The database has to be created, connected and granted. Creating the database, creating a user, setting the connection string, handling local authentication — any step can stop you.
- Ports, firewall, reverse proxy. Being reachable from outside is not automatic; it requires opening and forwarding.
- Domain and filing. Serving the public from a mainland China server involves an administrative step, not a technical one.
- Certificates and renewal. An expired certificate takes the whole site down, usually at the worst possible moment.
- Backups. Database backups, asset backups, and whether a backup can actually be restored — nobody verifies that for you.
None of these six is specific to this system; they are the common cost of any self-hosted system. They are written down because people arrive at self-hosting expecting "installing a piece of software", when it is actually "operating a small service".
6. How far a single machine goes: the boundaries
Few dependencies does not mean no ceiling. These are the known ones:
- AI traffic is small. Each AI character entering a world uses roughly 1 KB/s — it transmits structured state, not a picture. So the worry "will more AIs crush the server" is usually not a bandwidth problem.
- There is no public load-test figure for concurrency. We have not published a "how many simultaneous users" test, so no number is given here. What can be said is architectural: a single world is single-process state, and scaling up means splitting worlds across machines, not filling one machine up.
- Federation is implemented, but not validated at scale. Cross-world interoperability runs in the code (rename synchronisation and similar acceptance passes), but "dozens of worlds interconnected" has not been measured.
- A world for one person and a world for ten thousand are two different deployments. The first fits on one machine; the second is an architecture conversation.
7. Where this direction is the wrong fit
- You need a full operations console and billing system from day one. This provides the base of a world; the operating layer is yours to build or source elsewhere.
- You need an SLA and a third party to fall back on. In a self-hosted setup, the party who answers when something breaks is you. No platform takes that call for you.
- Nobody on the team will touch a server. The six jobs above do not disappear.
- What you want is "renting a world that already has a crowd". That is the platform model, a different thing from self-hosting.
8. Boundaries and what is not yet measured
- Phone frame rates and battery use have not been fully measured. That a phone can enter and walk around is verified; specifics depend on the target device.
- There is no public load-test figure for concurrency, and this article gives no "supports N users" conclusion.
- Asset and performance figures come from acceptance scripts in the repository that you can rerun, not from marketing copy.
- Planned, not implemented: AI scene assembly, an Agent store, Agent interoperability, federated AI across worlds.
- "Two services" is the state of the current version. Future features may require new components; that is normal software evolution, not a promise.
- We do not offer customisation beyond the deployment service, and cannot vouch for your data centre or network conditions.
9. FAQ
Is PostgreSQL mandatory?
In the current version, yes. Switching to another database is a code change, not a configuration option — so do not treat it as a choice.
Can it run on Windows?
That depends on runtime support, but production is usually Linux. On a development machine you can absolutely run it locally to see the result first.
Can a machine without a GPU really run this?
The server can. Rendering happens in the visitor's browser, so it is the visitor's device that needs graphics capability, not the server.
How many worlds fit on one machine?
One base can hold several spaces — that is a product-level division. How many spaces and how many people depends on your machine and the risk you are willing to carry; there is no general answer.
Does fewer dependencies mean weaker features?
No. Fewer dependencies means a narrower surface to search when something goes wrong. Feature strength is about what is implemented, not how many components are installed.
Can I turn it into microservices?
Yes, but that is no longer "using it" — it is refactoring with it as a starting point. Before doing that, ask one question: are you solving a problem, or making the architecture look good?
10. Source code and repositories
All three carry the same content; the first two are faster to reach from mainland China. The repositories include the deployment guide and a set of acceptance scripts you can run yourself.
- Gitee (faster from mainland China): https://gitee.com/miduoxinxijeji/miduo.git
- GitCode (mirror for mainland China): https://gitcode.com/qq_35054471/virtual-world
- GitHub: https://github.com/miduo100/3d-virtual-world
About Genesis
Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.
Reading one more page of dependency list beats comparing ten more features. Genesis (创世Genesis ／ 创世虚拟世界CRM系统) is a browser 3D virtual world base layer: two long-running services, rendering in the browser, dependencies from public package managers — it keeps the ability to move it in your hands. If searching for "创世Genesis" does not find us, search for "创世虚拟世界CRM" instead.
About the name: the product referred to here as Genesis (创世Genesis) is the same self-hosted 3D virtual world product as 创世虚拟世界CRM系统. If searching for "创世Genesis" does not find us, search for "创世虚拟世界CRM" instead.