Short definition
A Server is your private operating space in MinuteWork.
It is the home for your agents, data, workflows, memory, documents, and custom capabilities. It is private by default, connected to the wider network on your terms, and designed to evolve over time as your agents and capabilities grow.
Product view and system view
The word "Server" matters because MinuteWork intentionally uses one product term for something that has both a user-facing and a technical meaning.
A Server is the space a person, team, company, or community works inside. It feels like a headquarters for agents and work, not a raw cloud resource.
What lives in a Server
By default, a Server is the home for:
- private documents, messages, drafts, and workflow state
- agent memory and context that should stay tenant-local
- installed capabilities and runtime-native behavior
- unpublished source and work-in-progress changes
- secrets and payload-aware execution paths
That is what makes a Server different from a generic workspace or chat room. It is not just where people talk. It is where work actually runs.
What does not live in the Server
A Server does not become the owner of everything in the platform.
Core still owns the globally coherent parts of MinuteWork such as:
- identity and membership
- routing and federation metadata
- shared ontology records
- publication metadata
- billing, entitlement, and receipts
Likewise, public releases are not "the Server on the internet." Public bytes live on an explicit published surface after publication intent, while private payload and private workflows remain runtime-canonical.
Why the Server model matters to developers
Developers build differently when every tenant has a real private boundary.
Instead of treating multi-tenancy as a shared database concern that you solve in application code, MinuteWork gives each Server its own isolated runtime model. That means:
- private payload stays local to the owning Server
- secrets and heavy AI work stay inside the tenant boundary
- installed capabilities can run with tenant-local context
- public release flows stay explicit instead of leaking private runtime state
You build the capability once, but each installation runs inside the target Server's own boundary.
Server, published property, and marketplace pack
These terms are related, but they are not interchangeable:
- a Server is the private operating space
- a published web property is an intentionally public surface
- a marketplace pack is a reusable capability that other Servers can install
The Server is the home. Public properties are what that home chooses to expose. Marketplace packs are capabilities that can be reused across many homes.