Cripto Host Decentralized Hosting

The Problem

Publishing a traditional frontend can be straightforward. Publishing applications and assets using decentralized technologies often requires familiarity with IPFS, pinning, gateways, CIDs, storage providers, blockchains, domains, persistence and infrastructure.

The product question was: how much of that complexity could be hidden behind a simple deployment experience without removing the properties that make these technologies interesting?

My Role

My work sat between product decisions and technical choices. I was involved in the proposal’s discovery, technology research, backlog definition and MVP scoping, alongside participating in the architecture design and the trade-offs needed to keep the first version viable.

Because the project did not move into implementation, the work was focused on turning a broad idea about decentralized hosting into a proposal that could be discussed, prioritized and eventually built.

Complexity Should Stay Behind the Deploy

The central thesis was that developers should not need to understand all the underlying infrastructure to publish their project. The intended experience was:

connect repository → configure project → deploy

While the system would handle build, storage, persistence, versioning, CID, gateway and domain.

The proposal was not to hide decentralization: it was to make it accessible without requiring users to understand all the operational complexity behind it.

This Was Not About Building a New Blockchain

What Would Actually Be in the MVP

The initial MVP was defined with a deliberately lean scope. The exclusion exercise was as important as defining what was in: each item left out represented complexity that could be introduced later, backed by usage evidence.

A dashboard with projects, deployments and history; authentication; static site uploads; GitHub integration; automated builds; IPFS publishing; public links; CID history; and rollback formed the proposed core. Distributed microservices, multi-region infrastructure and advanced blockchain capabilities would come later.

Candidate Architecture

The proposed architecture was organized around four main blocks. Separating the control plane from the data plane was one of the central decisions: it would allow the storage infrastructure to evolve without rebuilding the core product experience.

Candidate architecture and evolution paths

The technical exploration below was produced during discovery. Some components represent possible future evolution and were not part of the initial MVP.

The Deploy Flow

A deployment would follow these steps conceptually. Developers would see only the beginning and the final result; each intermediate step would be the responsibility of a specific architecture component.

Avoiding Provider Lock-in

One of the most relevant technical decisions was the proposal for an adapter layer. The idea was that the rest of the application would work through standardized interfaces, so switching a provider would not require rebuilding the dashboard and core logic.

Storage Adapters: IPFS as the primary layer in the MVP, with Filecoin, Arweave and other providers as future possibilities.

Blockchain Adapters: Ethereum, Polygon, Base, Arbitrum and other networks when needed for specific features.

Gateway Adapters: public IPFS gateways, fallback options and custom domains.

This approach translated into portability, simpler maintenance, reduced vendor lock-in and the ability to evolve without rewriting the product core.

Starting Simple Without Closing Doors to Scale

This is perhaps the central technical product story of this case.

The initial strategy deliberately did not include Kubernetes, Kafka, Go or Rust, dozens of microservices, a proprietary global node network or multi-region infrastructure from day one.

The proposal was a modular monolith: TypeScript, NestJS, PostgreSQL, Redis with BullMQ, separate workers, Docker and a VPS with an external pinning provider.

The reasoning was direct: less initial complexity means lower cost, lower operational overhead, more speed to validate and a real possibility of separating components when usage justified that decision. Starting with complex distributed architecture before having any users would mean optimizing for a problem that did not yet exist.

Infrastructure and Costs

The initial infrastructure proposal was deliberately lean: a VPS for the main services, separate build workers, PostgreSQL, Redis, an external IPFS pinning provider, an initial public gateway, backups and basic monitoring.

The decision not to operate a proprietary global node network from the start was explicit. The cost, operational complexity and the need to validate the product before scaling infrastructure made that choice hard to justify at that stage.

Privacy, Security and Real Limits

The commercial proposal involved topics like privacy, data sovereignty and resistance to blocking. An important part of the product discovery work was separating what was marketing narrative from what were actual technical guarantees.

IPFS provides content addressing, distribution and the possibility of redundancy. But it does not automatically provide persistence (active pinning is required), encryption (content is public by CID by default), anonymity (gateways and nodes log access) or guaranteed uptime.

The MVP would have a centralized control plane: authentication, billing and orchestration would all be centralized components. Claiming that the product would be “fully decentralized” would not be technically defensible. Gateways and domains can still fail; availability would depend on the gateway infrastructure used.

This calibration exercise between commercial promise and technical reality was a core part of the discovery.

Roadmap

The roadmap was developed as planning during discovery, not as a delivery commitment. Discontinuation happened before any phase was started.

Phase 1: Functional MVP — Dashboard, authentication, uploads, automated builds, IPFS publishing, public links and CID history.

Phase 2: Modularity and commercialization — Plans, billing, custom domains, DNSLink and a consolidated adapter layer.

Phase 3: Web3 expansion — Filecoin and Arweave as storage options, ENS and additional capabilities for DApps.

Phase 4: Scale — Separating components where usage justified it, additional infrastructure and potentially distributed workers.

Where the Project Stopped

The proposal moved through discovery, technology research, MVP definition, backlog and architecture design. Development of the platform was never started. The initiative remained in the Cripto Host backlog and was later discontinued.

No feature was implemented. There are no users, product metrics or operational infrastructure associated with this proposal.

What This Project Demonstrates

• Technical Product: connecting product decisions, infrastructure and developer experience before committing to implementation.
• Product Discovery: turning a broad idea into a problem, proposal and scope that could be discussed and challenged.
• MVP Scoping: separating what was needed to validate from what could come later, and justifying each exclusion.
• Product Architecture: defining boundaries between the control plane, build engine, storage and distribution.
• Technical Trade-offs: avoiding premature complexity without closing off future evolution paths.
• Product × Engineering: translating technical research into backlog, requirements and product decisions.