A template for site builders and low-code tools.
Read the guide to learn how to deploy your own version of this template.
Multi-tenant applications serve multiple customers across different subdomains/custom domains with a single unified codebase.
For example, our demo is a multi-tenant application:
Another example is Hashnode, a popular blogging platform. Each writer has their own unique .hashnode.dev
subdomain for their blog:
Users can also map custom domains to their .hashnode.dev
subdomain:
This repository makes it easier than ever for creators to build their own platform.
Forget manually setting up CNAME records, wrestling with DNS, or making custom server rewrite rules with NGINX. With Vercel and the Platforms Starter Kit, you can focus on building the next big thing.
Vercel customers like Hashnode, Super, and Cal.com are building scalable platforms on top of Vercel and Next.js. There are multiple types of platforms you can build with this starter kit:
These are content-heavy platforms (blogs) with simple, standardized page layouts and route structure.
“With Vercel, we spend less time managing our infrastructure and more time delivering value to our users.” — Sandeep Panda, Co-founder, Hashnode
No-code site builders with customizable pages.
By using Next.js and Vercel, Super has fast, globally distributed websites with a no-code editor (Notion). Their customers get all the benefits of Next.js (like Image Optimization) without touching any code.
Multi-tenant authentication, login, and access controls.
With Vercel and Next.js, platforms like Instatus are able to create status pages that are 10x faster than competitors.
This working demo site was built using the Platforms Starter Kit and:
We also have another example of the Platforms Starter Kit that uses Supabase for the database and Slate.js for the text editor.
Should we be generating static webpages with getStaticProps
and getStaticPaths
at build time? It doesn't seem to be very scalable.
For scale, we recommend using Incremental Static Regeneration instead. This basically means that instead of generating all pages at build time, you only specify a subset of pages and then generate the rest on the fly. Then when someone requests that page, all subsequent requests will be cached on the Vercel edge. You can also use on-demand ISR to programmatically invalidate caches per page every time someone makes a change to it, which is what we do here.
Is it wise to be using the /_sites/[site]
path to serve all static pages/website? Wouldn't that lead to a significant amount of load on a single Next.js server?
The beauty about a serverless setup is you won’t have to worry about load since each request invokes a separate serverless function, and once it’s cached, you don’t invoke the server anymore (the page is served directly from the Vercel edge). Read more about the Vercel Edge Network and how caching works.
The MIT License.
A template for site builders and low-code tools.
Read the guide to learn how to deploy your own version of this template.
Multi-tenant applications serve multiple customers across different subdomains/custom domains with a single unified codebase.
For example, our demo is a multi-tenant application:
Another example is Hashnode, a popular blogging platform. Each writer has their own unique .hashnode.dev
subdomain for their blog:
Users can also map custom domains to their .hashnode.dev
subdomain:
This repository makes it easier than ever for creators to build their own platform.
Forget manually setting up CNAME records, wrestling with DNS, or making custom server rewrite rules with NGINX. With Vercel and the Platforms Starter Kit, you can focus on building the next big thing.
Vercel customers like Hashnode, Super, and Cal.com are building scalable platforms on top of Vercel and Next.js. There are multiple types of platforms you can build with this starter kit:
These are content-heavy platforms (blogs) with simple, standardized page layouts and route structure.
“With Vercel, we spend less time managing our infrastructure and more time delivering value to our users.” — Sandeep Panda, Co-founder, Hashnode
No-code site builders with customizable pages.
By using Next.js and Vercel, Super has fast, globally distributed websites with a no-code editor (Notion). Their customers get all the benefits of Next.js (like Image Optimization) without touching any code.
Multi-tenant authentication, login, and access controls.
With Vercel and Next.js, platforms like Instatus are able to create status pages that are 10x faster than competitors.
This working demo site was built using the Platforms Starter Kit and:
We also have another example of the Platforms Starter Kit that uses Supabase for the database and Slate.js for the text editor.
Should we be generating static webpages with getStaticProps
and getStaticPaths
at build time? It doesn't seem to be very scalable.
For scale, we recommend using Incremental Static Regeneration instead. This basically means that instead of generating all pages at build time, you only specify a subset of pages and then generate the rest on the fly. Then when someone requests that page, all subsequent requests will be cached on the Vercel edge. You can also use on-demand ISR to programmatically invalidate caches per page every time someone makes a change to it, which is what we do here.
Is it wise to be using the /_sites/[site]
path to serve all static pages/website? Wouldn't that lead to a significant amount of load on a single Next.js server?
The beauty about a serverless setup is you won’t have to worry about load since each request invokes a separate serverless function, and once it’s cached, you don’t invoke the server anymore (the page is served directly from the Vercel edge). Read more about the Vercel Edge Network and how caching works.
The MIT License.