Basecamp: Your Base of Operations on the Logos Frontier
Private by default, local by design, your gateway to the Logos ecosystem
Dr. Corey Petty
Every expedition needs a base of operations. A private, secure shelter already equipped with supplies and communications, so you can spend your time exploring, not building from scratch.
That's Basecamp.
Basecamp is a ready-to-run distribution that you deploy on your own hardware, under your control. From the moment it’s installed, you’re standing on your own ground, not connecting to someone else’s infrastructure. The Logos Runtime is already running locally, core modules are loaded, and essential applications — wallet, messenger, file sharing, blockchain explorer — are ready to use from day one.
This changes the relationship between the user and the system. When everything runs locally, privacy is the default state. Because you control the environment, you control your data.
What Basecamp actually is
Basecamp is the launcher and unified surface of the Logos stack. It is an executable that wraps the Logos Runtime and does three things:
- Initialises the Logos Core environment on startup
- Discovers and loads UI plugins from whatever modules are installed
- Presents a unified interface where users interact with everything
That last point is important to understand. Basecamp doesn't do the work, it surfaces it to users. The logic for the wallet lives in the blockchain module, messaging in comms, and file-sharing in storage. Basecamp is the place all of those show up, consistently, in one place.
Think of it as the user-facing access point for a modular, unified stack — the thing that turns a collection of powerful, interoperable modules into a coherent experience.
Local-first, by conviction
Every layer in the stack you're about to see — Runtime, Network, Modules, App Backends — runs on your machine. Not on a cloud server you rent, not behind an API you call, not in a data centre that logs your queries, graphs your social connections, and sells the patterns.
The entire stack is local-first infrastructure, operated as a peer-to-peer network where your node is a full participant, sourcing and leveraging the modules it needs to run your application.
Centralised services are custodial by nature: they require your trust and can access your metadata, if not your actual data, in return for convenience. The trade-off is rarely made explicit. Who you message, when, how often, from where — that metadata is often more revealing than the content itself, and conventional architectures funnel all of it through chokepoints that can observe, store, and monetise it.
Basecamp's stack is designed around the opposite assumption. The P2P network layer means your messages, files, and transactions flow between peers, not through a single relay. The modules run locally, so your wallet state, your chat history, and your file index never leave your device unless you choose to share them. There is no sign-up, no account on a remote server, no quiet background sync to infrastructure controlled by a single entity.
A diagram you can walk through
The Logos stack is layered: the Logos Runtime at the foundation, the network on top, modules stacked above (each higher module depending on the ones beneath it, implicitly composing into something useful), and app backends at the apex. Basecamp is one of three ways in. The diagram illustrates this structure. Pick a use case from the tabs and the slice of the stack it leans on lights up, with live arrows tracing the data flow.
Run a node with no UI
Headless nodeFor servers, validators, infrastructure. The headless entry skips the App Backends layer entirely but reaches into modules at any depth — a validator drives LEZ on top of Blockchain, a storage provider drives Files on top of Storage, a relay drives Chat on top of Delivery. Runtime up, P2P peers connected.
The diagram autoplays through every use case defined below; click any tab to pin it as you continue reading. The rest of this article points back at specific views to ground each idea in something visual.
What you get out of the box
The default Basecamp installation ships with Simple Apps for each core module:
- Wallet — managing accounts and assets on the Logos blockchain
- Chat interface — encrypted messaging via the Logos comms layer
- Filesharing tool — private, decentralised file storage and sharing
- Blockchain / LEZ explorer — inspect the chain, transactions, and execution zones
The Default Basecamp user tab in the diagram shows what this looks like in motion: each Simple App is a UI plugin at the top of the Basecamp zone, and each one lights up its own slice of the stack in parallel. The wallet rides LEZ → Blockchain. The messenger rides Chat → Delivery. The dashboard reads straight from the blockchain. Same launcher, several flows, no duplication.
The single-purpose tabs — such as DEX trader, Private messaging, and File sharing — isolate each of those flows. The arrows show the direction of dependency: a chat user's bytes flow through Chat → Delivery → P2P, never touching the blockchain. A trader's flow through LEZ → Blockchain, never touching Storage. This flow is what makes the Logos stack truly modular and interoperable.
These aren't separate apps stitched together; they load from Basecamp's unified shell using a consistent design system and are discovered automatically by the Package Manager.
Module-agnostic by design
Basecamp doesn't care which modules you have installed. It discovers them, loads their UI plugins, and surfaces them to you whatever the configured profile contains.
This is an intentional design feature. The stack composition is defined by which modules are selected, not by the launcher. This allows a developer building a specialised Logos distribution to swap the module set entirely, using only what they need. Basecamp simply loads what is there, offering one launcher for many possible stack configurations.
The Atomic swap tab in the diagram makes this case visually. A trustless cross-chain swap composes the existing Swaps module on top of LEZ (Logos side) with a proposed Monero module (XMR side, shown with a dashed border). The DEX UI doesn't change; the user's path through the stack does. Adding a new module with new capabilities requires no work on the part of the launcher, which just traces the data flow through the new stack configuration.
This composability is where Basecamp draws from its inspirations: the Mist Browser was an early reference point — an entry-level gateway into an ecosystem — and LeechCraft, a modular live environment where every capability is a plugin. Basecamp's ambition is to go further: composability at the ecosystem layer, built on a privacy-preserving, decentralised foundation.
Three ways in, one stack
Basecamp is the default launcher, but it is not the only way for users to access the Logos stack. The three header zones at the top of the diagram show the available options:
- Logos Basecamp — the unified launcher most users want. Discovers modules, surfaces their UIs, gets out of the way.
- Standalone App — when you don't want a launcher at all. A single binary ships with its own UI and just the modules it needs. Useful for purpose-built clients (the Standalone app tab walks through a focused DEX example) where Basecamp's discovery model would be unnecessary overhead.
- Headless Node — no UI surface, just a CLI. Useful for servers, validators, or infrastructure. The Headless node tab shows that headless can drive modules at any depth — a validator drives LEZ on top of Blockchain, a storage provider drives Files on top of Storage, and a relay drives Chat on top of Delivery. Runtime up, P2P peers connected.
The choice between the three is about what surface you want, not what's underneath.
For developers: QML is the easy path
Basecamp is also where the module-building story meets deployment. Once
you've scaffolded a module with the lm CLI and the
module-builder tooling, Basecamp is how you actually run it. The
Module developer tab in the diagram traces the path involved: the
new module gets detected by the Package Manager module, listed in the
Package Manager UI, and auto-loaded by Basecamp on its next launch. The
rest of the stack is what your module composes against.
The team is moving toward a QML-only UI layer for module frontends, with the C++ application backend running in a separate process. The practical upshot of this approach is that if you build your module UI in QML, it works in Basecamp without friction. The system is intentionally designed this way — the examples and tooling are being built to make QML the path of least resistance.
Current support: Linux and macOS, with C++ for module development. Windows, Android, iOS, and additional SDK languages (Rust, JS, Nim) are in active development.
The road ahead
Basecamp is currently in active development on the Logos Testnet v0.1.2, with Testnet v0.1.3 set to mark a significant UX step forward, delivering a new docking widget system (KDDockWidgets), onboarding flows, and settings encryption. That's when Basecamp stops being a developer testing surface and begins to resemble the first-class user experience the frontier deserves.
Start here
Basecamp is available now for Linux and macOS.
- Repository: github.com/logos-co/logos-basecamp
- Builder Hub: build.logos.co
The frontier awaits. Basecamp is how you reach it.