anti-cloud

anti-cloud is a single-binary prototype for a sovereign data fabric. It is designed as a local-first, resilient, and partially distributed data runtime that can persist encrypted records, support vector-style similarity search, and replicate state across cooperating nodes using gossip and CRDT-style conflict resolution.

The project is intentionally opinionated: it combines durable on-disk storage, embedded networking, a gRPC API, a REST control plane, and a lightweight vector index into one executable. The goal is not to be a full production database, but to demonstrate how a small, self-contained system can approach durability, replication, and service exposure without depending on a separate infrastructure stack.

What this project is trying to demonstrate

anti-cloud is best understood as a compact reference implementation for a sovereign data node. It explores several ideas at once:

Anti-Cloud is not a phone app or a traditional website

Anti-Cloud is not an app you download on your phone, and it is not a traditional website you browse. It is a standalone system binary: a compiler-generated executable file, similar to a .exe on Windows or a raw binary executable on Linux and macOS. It acts as a local-first backend infrastructure engine.

Think of it as a single, ultra-secure piece of industrial equipment for software developers. Instead of renting database services and server infrastructure from cloud providers, developers run this binary directly on their own hardware.

When a developer launches the binary on a computer or server, it turns that machine into an intelligent, private cloud node. The binary contains several core components running simultaneously:

1. The database engines, which manage encrypted files on disk and local AI vector data.
2. The mesh communicator, which listens on a network port using a gossip protocol to discover other machines running the same binary and form a private network.
3. The control plane, which hosts an embedded HTTP server with a built-in dark-mode dashboard and a developer-facing REST API.

Because the runtime is designed to be zero-dependency, running it is simple. Developers can launch it directly from a terminal or deploy it in a containerized environment without installing a separate web server or database stack.

Running it natively

A developer can drop the compiled binary onto a server and start it from the command line:

./anti-cloud -name=node-alpha -grpc=50051 -gossip=7946

That command starts the node's storage engine, initializes cryptographic identity and transport security, and opens its network ports.

Running it in containers

For automated or DevOps-driven environments, the binary can be deployed with Docker. A typical deployment mounts a local storage path and exposes the control plane and gRPC service:

docker run -d -p 8080:8080 -v /my/local/data:/data anticloud/node:latest

How people interact with it

Once the binary is running, users interact with it in two primary ways:

• Administrators can open a browser to the embedded dashboard at http://localhost:8080/dashboard to inspect the node, view cluster state, and monitor local activity.
• Developers can connect their applications to the running node through the REST API or gRPC interface, writing and reading data without needing proprietary infrastructure drivers.

For example:

curl -X POST http://localhost:8080/api/v1/store \
  -d '{"key": "intel_01", "value": "secure_payload"}'

Why organizations use it

This model is attractive for hospitals, financial institutions, public-sector organizations, and other environments that need modern cloud-style capabilities without sending sensitive data to centralized third-party providers. Instead of relying on external infrastructure, they can install Anti-Cloud directly onto their own computers or servers, link those nodes into a private fabric, and retain direct control over their data, networking, and operational boundaries.

• durable local persistence with embedded disk storage instead of volatile in-memory maps
• encrypted record storage that survives restarts and supports later retrieval
• merge-friendly replication using last-write-wins registers as a simple CRDT primitive
• peer discovery and event broadcast in a small mesh network
• a service layer that exposes data through gRPC and REST
• embedding a vector search layer for similarity-style retrieval over stored documents

This makes it suitable for prototyping ideas around resilient edge computing, distributed data ownership, offline-first storage, or self-hosted data fabrics.

High-level architecture

The runtime is organized around a handful of cooperating subsystems:

1. Storage layer

   • Built around BoltDB for durable local persistence.
   • Stores encrypted payloads and CRDT register state on disk.
   • Supports basic batch writes, key listing, backup, and restore.

2. Vector engine

   • Maintains an in-process vector index with persistence.
   • Supports upserts and similarity queries using cosine similarity.
   • Uses a simple HNSW-inspired indexing structure for approximate nearest-neighbor style behavior.

3. Networking layer

   • Uses a gossip-style mesh for peer discovery and propagation of mutations.
   • Broadcasts state changes across known peers and allows nodes to converge over time.

4. Service layer

   • Exposes data operations through gRPC.
   • Offers a small REST control plane and dashboard for local inspection and administration.

5. Security and trust layer

   • Encrypts values before persisting them.
   • Uses a shared master key in the current prototype for demonstration purposes.

Core capabilities

Durable storage

The storage engine is backed by BoltDB and writes records to disk rather than keeping everything in memory. This allows the node to survive restarts and continue serving data after a crash.

Features include:

• encrypted key/value writes
• CRDT-style register storage for merge-friendly replication
• basic batch inserts
• blob-style storage helpers
• backup and restore operations
• key listing for inspection

CRDT-style replication

The storage engine stores values as last-write-wins register objects. When a mutation arrives from a peer, the local node compares timestamps and only adopts the newer state when appropriate. This supports a simple convergence model that is safe enough for prototyping distributed replication without requiring a full consensus system.

Gossip-based discovery

The network layer uses a lightweight peer discovery and broadcast model. Nodes can discover one another, exchange metadata, and propagate changes to the rest of the cluster over time. This is intentionally simple but useful for understanding how data can move across a federation of cooperative nodes.

Vector search

The vector subsystem maintains document embeddings and metadata in a persisted index. Each upsert stores an ID, values, and associated metadata. Queries compute cosine similarity against the stored vectors and rank results by relevance.

gRPC access

The application exposes a small RPC surface for interacting with the runtime:

• storing records
• reading records
• proxying reads to peers when local state is missing
• upserting vectors
• querying vectors

Embedded control plane

The HTTP server exposes a small operator-friendly control surface for local inspection and experimentation. It includes:

• a dashboard view
• a basic store API
• cluster status endpoints
• a simple interface for interacting with the node over HTTP

Repository layout

• main.go – application entrypoint, runtime startup, service wiring, and request handlers
• core/ – storage, crypto, vector, CRDT, and HTTP control-plane logic
• network/ – gossip mesh and MPC-related helpers
• proto/ – protobuf service definition and generated bindings
• docs/ – supporting notes and design documentation
• .github/workflows/ – CI workflow definition

Prerequisites

To build and run the project locally, you need:

• Go 1.25 or newer
• a working terminal environment
• optional: grpcurl for exercising the gRPC API from the command line

Install dependencies with:

go mod download

Run locally

Start the node with:

go run .

The service will start with the following default behavior:

• gRPC on port 50051
• HTTP control plane and dashboard on port 8080
• local data files under the data directory

You can also pass a few simple flags:

go run . -name node-beta -grpc 50052 -gossip 7947 -seeds 127.0.0.1:7946

Useful flags

• -name: sets the node identity
• -grpc: sets the gRPC listening port
• -gossip: sets the gossip port
• -seeds: provides a comma-separated list of peer addresses to join

Default runtime behavior

When the node starts, it will:

• initialize a storage database under the node-specific data directory
• create an encrypted sample record on disk
• initialize a vector index and insert a few demo vectors
• start the gossip mesh and join any provided peers
• launch the gRPC service and HTTP dashboard

The runtime writes data files into a node-specific path such as:

data/node-alpha/storage.db
data/node-alpha_vectors.db

The directory layout is intentionally simple so that experiments can be run locally without setting up external infrastructure.

Example endpoints

Once the service is running, the following endpoints are available:

• Dashboard: http://localhost:8080/dashboard
• REST store API: http://localhost:8080/api/v1/store
• Cluster status: http://localhost:8080/api/v1/cluster
• gRPC service reflection/list: grpcurl -plaintext localhost:50051 list

Example REST requests

Write a value

curl -X POST http://localhost:8080/api/v1/store -d '{"key":"intel_01","value":"secure_payload"}'

Read a value

curl http://localhost:8080/api/v1/store/intel_01

Example gRPC calls

Upsert a vector

grpcurl -plaintext -d '{"id":"doc_3","values":[0.1,0.2,0.3,0.4],"metadata":{"origin":"demo"}}' localhost:50051 anti.SovereignService.UpsertVector

Query vectors

grpcurl -plaintext -d '{"values":[0.1,0.2,0.3,0.4],"top_k":3}' localhost:50051 anti.SovereignService.QueryVectors

Store a record

grpcurl -plaintext -d '{"key":"alpha","value":"hello-from-grpc"}' localhost:50051 anti.SovereignService.PutRecord

Retrieve a record

grpcurl -plaintext -d '{"key":"alpha"}' localhost:50051 anti.SovereignService.GetRecord

Docker

The project includes a basic Dockerfile for containerized deployment.

docker build -t anti-cloud .
docker run --rm -p 8080:8080 -p 50051:50051 anti-cloud

This is useful for testing the runtime in an isolated environment and for validating that the binary boots with the expected ports and local file paths.

Development notes

Code organization

The implementation splits responsibilities into a few focused packages:

• core/ contains storage and vector logic, plus the HTTP control plane.
• network/ handles mesh membership and replication helpers.
• proto/ defines the service contract used by gRPC.

Current design tradeoffs

The system is intentionally lightweight and educational. Some implementation choices are simplified on purpose:

• encryption uses a static shared key in the prototype runtime
• replication is eventual and based on simple message propagation
• the vector index is not a full production-grade ANN engine
• the control plane is minimal and aimed at local exploration rather than enterprise administration

These tradeoffs keep the prototype small and understandable while still demonstrating the broader architecture.

Security considerations

This repository is a prototype, not a hardened production system. As a result:

• the master key is embedded in the runtime for demonstration purposes
• authentication and authorization are not yet implemented in the service layer
• the gossip mesh is intentionally simple and should not be treated as a secure transport layer by itself

For realistic deployment, you would want to add stronger key management, authentication, TLS, access controls, and production-grade persistence and monitoring.

Troubleshooting

Port already in use

If the gRPC or HTTP ports are already occupied, change the flags when starting the binary:

go run . -grpc 50052 -gossip 7947

Data directory issues

If the node appears to be starting with stale or unexpected state, remove the relevant data directory and restart:

rm -rf data

gRPC tooling not installed

If grpcurl is unavailable, you can still interact with the system through the HTTP endpoints or by extending the service layer with your own client.

License

This project is licensed under the Apache License 2.0.

Copyright 2026 Magnexis

See LICENSE for the full text.

Tests

Run the test suite with:

go test ./...

The current repository includes unit coverage for the core storage and vector logic and validates that the runtime still compiles correctly after structural changes.

Future direction

The next logical evolution for this project would be to deepen it in several directions:

• add proper authentication and authorization
• move from a prototype key to a real secret-management strategy
• support TLS and mutual authentication for the gRPC and HTTP surfaces
• improve cluster consistency and failure handling
• add richer observability and metrics
• expand the vector layer into a more complete ANN implementation

That said, the project already provides a usable foundation for experimenting with a sovereign, self-contained data fabric in a single binary.