Introduction
Project Name: AnchorHost
Name of the organization or individual submitting the proposal: Abhay Salvi (Individual)
I am a Software Developer by profession, and a certified Google Professional Cloud Developer. My past work includes building HIPAA compliant healthcare apps (mainly the backend part), Insurance ETL pipelines, and a few open-source project contributions.
Here’s my GitHub URL: https://github.com/git002
Describe your project
AnchorHost is a browser-based static website hosting platform built on Sia that combines the simplicity of traditional hosting platforms with the ownership benefits of decentralized storage. The project aims to provide a deployment experience similar to Netlify while ensuring users retain control over their website data on sia.
Users authenticate using email/password or Google Sign-In and through a BIP-39 recovery phrase. Website assets are uploaded directly to Sia through SDK in browser, while AnchorHost’s backend only stores metadata, routing configuration, deployment history, and object references required to serve websites.
Deployed websites are distributed globally through Cloudflare’s CDN. On cache misses, AnchorHost retrieves content from Sia using long lived share URLs and streams it to users without exposing the share URL endpoints.
The platform also supports data migration by allowing users to export metadata and object references, enabling compatible hosting services to reconnect to existing Sia objects without re-uploading website assets. This will ensure there’s no vendor lock-in.
How does the projected outcome serve the Foundation’s mission of user-owned data? What problem does your project solve?
Current static hosting providers such as Netlify, GitHub Pages, or TiinyHost tightly couple deployment access with ownership of the storage layer. If the provider changes pricing, suspends an account, or shuts down, users must manually migrate and re-upload their websites elsewhere.
Whereas on AnchorHost, website assets will live on Sia under identities derived from the user’s own recovery phrase instead of being controlled entirely by the hosting provider. The platform acts as a deployment and serving layer rather than a permanent storage gatekeeper.
The goal is to make decentralized storage usable for developers, freelancers, or bloggers without requiring them to understand Sia internals, contracts, or storage providers. Users interact with a familiar deployment workflow while Sia handles encryption, redundancy, and storage distribution underneath.
Every deployed site creates real-world storage demand on the Sia ecosystem while demonstrating a practical consumer-facing use case for user-owned infrastructure.
Tech Stack
- SvelteKit (Sia JS SDK for browser upload and server side reading share URL objects)
- Firebase based Authentication
- PostgreSQL
- Docker & Google Cloud Run
- Cloudflare CDN
Jurisdiction Compliance
Are you a resident of any jurisdiction on that list?
No
Will your payment bank account be located in any jurisdiction on that list?
No
Grant Specifics
Amount Requested
$8,000 USD
| Item | Amount |
|---|---|
| Development (3 months) | $7,000 |
| UI/UX Design | $500 |
| Infrastructure & domain | $500 |
| Total | $8,000 |
Infrastructure includes Google Cloud Run, database hosting, Cloudflare, Secret Manager, monitoring, and deployment tooling. Sia storage costs will be handled directly between users and the sia indexer.
High-Level Architecture Overview & Security Practices
User Flow
-
User signs in with Google or email/password
-
User generates or enters a recovery phrase in-browser
-
Sia SDK derives the App Key client-side in browser for the active session only. Files will get uploaded directly from browser to Sia
-
After upload, the frontend would fetch required info (obj id and share URL) in a variable and pass it to backend which will securely store subdomain mappings, route mappings, deploy history, object references, and long-lived share URLs.
-
Visitors access websites behind Cloudflare CDN for better performance.
-
On CDN cache miss: backend resolves the requested route, retrieves the stored object share URL, and downloads the object from Sia on server side with server’s own app key (stored safely in cloud KMS), then it streams the decrypted file to Cloudflare with appropriate MIME type. This way share URL stays hidden from public.
The share URL is required because, on a CDN cache miss, Cloudflare requests the file from the origin. Since users own and encrypt their files, the backend cannot serve them directly unless it either stores a copy of the file or has access to the user’s seed phrase.
A long-lived share URL solves this problem by granting the backend controlled access to the file when needed, without requiring storage of the user’s seed phrase or maintaining duplicate copies in GCS, AWS S3, or any other storage service. This allows us to rely exclusively on Sia for storage while preserving the security and ownership guarantees of user-controlled encryption.
Security Practices
- Recovery phrases will never be transmitted to the backend
- User App Keys will never be stored server-side or in browser storage
- App Keys will exist only in memory during the active session
- Firebase Auth and JWT validation on protected API routes
- Least-privilege Cloud Run service accounts
Goals and Timeline
Month 1: Core Platform & Frontend Infrastructure
- SvelteKit setup
- Firebase Auth integration
- Direct browser-to-Sia uploads
- Upload progress tracking
- Automatic subdomain generation
- Multi-file route mapping system
Success Criteria:
Users can sign in, upload a static site, and access it on a generated subdomain.
Month 2 — CDN Serving & Deployment Management
- Cloudflare CDN integration
- CDN cache miss routing flow
- Deploy history UI
- Rollback support
- Cache invalidation on deploy
- API rate limiting and backend hardening
Success Criteria:
Sites are globally cached through Cloudflare with functioning deploy history and rollback support.
Month 3 — Portability, Stability & Public Release
- Exportable deployment metadata format
- Migration documentation
- Error handling and monitoring improvements
- Production stability testing
- Public landing page
- Dockerized deployment setup
Success Criteria:
Users can export deployment metadata and reconnect deployments on compatible hosts without re-uploading assets.
Target User
Users currently relying on Netlify, GitHub Pages, or Tiiny Host who want the same simple path but with user-owned hosting infrastructure. Be it freelancers, developers, or bloggers who don’t want to be vendor locked, or silenced on the internet.
Potential Risks
- The Sia SDK is still evolving and may introduce breaking changes.
- Cloudflare costs may go over their generous free tier if usage increases.
Future plans
Currently, the user has to enter his/her seed phrase again and again after closing the browser window as we don’t store it. The UX won’t be very great here. In future we can offer a Tauri based desktop app as well that would hold the secrets much better so user won’t have to enter the seed phrase again and it will store in OS keychain system securely for better UX.
Development Information
Will all of your project’s code be open-source?
Yes. All project code will be released under the MIT license.
Repository
https://github.com/git002/anchorhost
Do you agree to submit monthly progress reports?
Yes.
Contact Info
Email: [email protected]