Deplit: My attempt to create Vercel

Deplit: My attempt to create Vercel

Table of Contents

Introduction

Deplit is a static site hosting platform similar to Vercel, Netlify, and Cloudflare Pages. Itā€™s not as feature rich as these platforms, but itā€™s a good starting point to understand how hosting platforms work under the hood.

Live: https://deplit.tech
GitHub: https://github.com/mdhruvil/deplit
YouTube video showcasing Deplit: https://www.youtube.com/watch?v=a4w8_rXajl4

Features

  • āš” Instant Rollback - One-click rollback to previous deployments
  • šŸ“¦ Preview Deployments - Preview your deployments before production.
  • šŸŒ Global CDN - Serve your site from nearest to your users
  • šŸš€ Instant Automatic Deployments - Push to GitHub, get instant deployments
  • šŸ”— Subdomains - Free .deplit.tech subdomains for all projects
  • šŸ“Š Build Logs - Real-time build monitoring and detailed logs
  • šŸ’»ļø Serverless Function (Soon) - Deploy your SSR or ISR apps to deplit

But Why ?

The main motive behind creating Deplit was to understand how hosting platforms work. What happens when I push code to GitHub? How is it built? Where is it built? How is my site served? Why is it so fast? To know the answers to these questions, I began researching. Thatā€™s when I came across this blog post: Behind the scenes of Vercelā€™s infrastructure by Lydia Hallie. This blog post is bit outdated. Vercelā€™s architecture has evolved a lot with the introduction to Vercelā€™s builds infrastructure and Fluid Compute. See this tweet/xeet by leerob. However, the core concepts are still the same. So I started implementing these concepts in my own way, and thatā€™s how Deplit was born.

Well some people say Vercel is just a glorified AWS wrapper, but trust me itā€™s more than that. With features like zero config deploys, instant rollbacks, preview deployments and more. Vercel handles a lot of complexity out of the box. And DX is far more better than AWS.

What is Vercel?

If you have been living under a rock and donā€™t know what Vercel is, hereā€™s what ChatGPT describes it:

Vercel is a platform as a service (PaaS) designed to simplify the deployment of web projects. It offers a seamless CI/CD experience, allowing developers to easily deploy static websites, server-rendered applications, and APIs. With Vercel, developers can concentrate on building and improving their applications without having to manage the underlying infrastructure.

How do Vercel/Deplit/Others works?

All these hosting platforms work somewhat similarly. Here Iā€™ll explain what happens when you deploy a site on Deplit.

High-level overview

Hereā€™s a high-level overview:

  1. You create a project on Deplit and connect your GitHub repository.
  2. Deplit starts listening to your GitHub repository for any push events.
  3. You push code to GitHub.
  4. GitHub notifies Deplit about newly pushed commit.
  5. Deplit creates a new deployment and adds it to a build queue.
  6. The builder is spawned. It picks up the deployment and starts the build process.
  7. The builder clones the repository, installs dependencies, builds the project and uploads the build artifacts to a storage bucket.
  8. After successful build, the builder notifies Deplit about the successful build.
  9. Deplit updates the deployment status and serves the site from this new deployment.

From overview, you can tell there are two main components involved in this process: the builder and the CDN/proxy. Letā€™s dive deeper into each of them.

Builder

Deplit Builder Architecture

When you create a project on Deplit and connect your GitHub repository, Deplit starts listening for push events using GitHub App webhooks. Every time you push code to GitHub, GitHub notifies Deplit about the new commit via these webhooks.

Deplit then creates a new deployment for all projects connected to that repository and adds it to the Azure Build Storage Queue, which triggers the Spawner, an Azure Function configured with a Queue Trigger.

Spawner then spawns a new Azure Container Apps Job which has two containers:

  1. Build Container: Responsible for building the project.
  2. Sidecar Container: Handles communication with the Deplit API and uploads build artifacts to the storage bucket.

Now, you might be wondering: Why not use a single container for both tasks? The reason is isolation. The container running the build process should be completely isolated from Deplitā€™s system to prevent user code from accessing sensitive APIs or internal infrastructure. Thatā€™s why all interactions with Deplitā€™s API and the uploading of build artifacts are handled exclusively by the sidecar container. Communication between the two containers is authenticated using a shared secret so the build process canā€™t communicate with the sidecar container. And of course, the build process doesnā€™t have access to this shared secret.

Both Harkiratā€™s, Piyush Gargā€™s implementations have this critical vulnerability, where the build process directly has access to sensitive secrets.

After successful build, the sidecar container uploads the build artifacts to the storage bucket and notifies Deplit about the successful build.

The artifacts are stored in Azure Blob Storage under the <project-id>/<commit-hash>/ directory, so multiple deployments of the same project can coexist without conflicts.

Why Deplit is fast?

Deplit Proxy Architecture

This is the most important and interesting part of Deplit. At the heart of its speed is the proxy, which is responsible for serving the site from the nearest edge location to the user.

This proxy is implemented using a Cloudflare Worker with a custom route pattern: *.deplit.tech/*. It handles all requests to Deplit subdomains and routes them to the correct deployment.

When a request comes in,

  1. The proxy checks about the site:deployment metadata in the Cloudflare KV store for that subdomain.
  2. If it doesnā€™t exists, it returns a 404 page.
  3. If it does exist, it looks something like this:
{
  "projectId": "f8b9e082-83b3-45df-8b76-c1fe00a9e969",
  "commitHash": "c14f5edc9205f6f780b8321374ad513fdb97263a",
  "spa": true,
  "htmlRoutes": {
    "/": "index.html"
    // more routes
  }
}
  1. The proxy then constructs the URL for the requested resource based on the metadata.
  2. This URL is used as a cache key for the Cloudflare cache.

Deplit doesnā€™t use Cloudflare CDN directly, but it leverages the same underlying caching layer used by Cloudflareā€™s CDN.

  1. If the resource is already cached, it is served instantly.
  2. If not, the proxy fetches it from Azure Blob Storage using a URL like: https://<deplit-blob-id>.blob.core.windows.net/<project-id>/<commit-hash>/<resource-path>
  3. Once fetched, it is cached for subsequent requests, delivering blazing-fast performance.

How fast is Deplit?

How fast are deployments on Deplit and Vercel ? I did a quick benchmark to check which is faster ?

Conditions:

  • Same project deployed on both. I have used https://github.com/mdhruvil/deplit-next for testing.
  • Browser cache disabled in DevTools
  • CDN cache: HIT. Both Deplit and Vercel uses CDN to serve files. This benchmark assumes that the files are cached at CDN.

Here are results for average load time for all the requests:

šŸš€ Deplit: ~93.38 ms
šŸš€ Vercel: ~79.47 ms

Deplit is ~13ms slower than Vercel. While Vercel is technically faster, Deplitā€™s sub-100ms average load time is still very impressive, especially considering itā€™s built by a student!

See my linkedin post for images and more information: linkedin post

Far more to go

Even though I have built something that can deploy static sites, Deplit is nowhere near Vercel. But Deplitā€™s current architecture makes it easy to add new features like:

  1. Serverless Functions/Edge Functions:

    • Deplit uses vercel CLI to build projects which outputs artifacts compatible with Vercelā€™s Build Output API v3.
    • This means that Deplit can support serverless functions, edge functions and SSR/ISR apps with minimal changes.
    • All I need to do is implement a custom router that understands the Vercelā€™s Build Output API v3.

  2. Web Analytics:

    • Since the proxy worker is invoked for every request, I can plug some custom logic to track page views and other analytics data.

  3. Image Optimization:

    • Using the same proxy worker, Deplit can offer on-the-fly image optimization via Cloudflare Image, similar to Vercelā€™s image optimization feature.

  4. ā€¦and many more:

    • The foundation is set. With a flexible proxy and clear build output standards, Deplit is ready to grow.

Conclusion

Building Deplit has been one of the most fun and challenging projects Iā€™ve ever worked on. It has given me an understanding of how hosting platforms work and the complexities involved in building such systems.

If you have any questions or feedback feel free to reach out to me on any of the platforms below. Iā€™d love to chat about this project or anything else youā€™re working on.

Peace out! āœŒļø