Vercel vs Blocks OS: Which fits you the most
Where each platform succeeds, and the one project type where the comparison comes to an early end: multi-tenant business software that must be hosted on infrastructure you manage.
Where each platform succeeds, and the one project type where the comparison comes to an early end: multi-tenant business software that must be hosted on infrastructure you manage.
Two products sharing one verb
An App can be deployed on Vercel. You can deploy an app on Blocks OS. The verb changes roles in each of the sentences.
Vercel is a frontend cloud. Connects to a repository which is detected and automatically builds and serves the result from a global edge network, with serverless functions (Fluid compute) for the code that must be executed server side. That is what it is and it's a good product.
SELISE Digital Platforms' Blocks OS is an application platform. It is ten services (identity, data, workflow automation, localization, monitoring, release management, the utilities layer covering mail, notifications and payments, plus the AI and core layers), and a CLI to build efficiently with Blocks. One of the 10 services is deployment.
When your product is the frontend itself, marketing site, docs, store front, this comparison is short and Vercel wins it. If you're the system, and the frontend is a user interface for that system, then there isn't as much overlap as the shared vocabulary might imply.
What ships on day one
Capability | Vercel | Blocks OS |
|---|---|---|
Hosting | Global edge network, preview deployments | Kubernetes via Tekton pipelines, custom domains |
Runtime | Serverless functions with Fluid compute | .NET 10 and Python services, background workers |
Authentication | Wire up a third-party provider | First-party IAM: OIDC, SSO, MFA, organizations, roles, sessions |
Database | Marketplace install (Neon, Supabase, Upstash) | Managed storage by default, or your own database via connection string |
API layer | Your code | Generated CRUD and GraphQL from schema definitions |
File storage | Marketplace install | Included, with Azure Blob, S3-compatible, or SFTP providers |
Email, notifications, workflows, localization, payments | Marketplace subscriptions and libraries | Platform services with CLI administration |
Multi-tenancy | Build it into every query | Tenant key on every request across services |
Self-hosting | Not available | The full platform as a Docker Compose stack |
Observability | Runtime logs, integrations | Uptime monitors, incidents, logs, traces, metrics included |
Authentication
The Blocks IAM ships as a whole service: as an ASP.Backend using NET Core API and Frontend using React Admin application. Sign-in and Sign-up with Social Providers / GitHub SSO. OIDC flows and client management. Sessions and devices. MFA using authenticator apps, backup codes and tenant-wide policy. Personal access tokens. Users, organizations, roles and permission grants.
It also does what most platforms leave to you: the token exchange as per RFC 8693 to be done in the background. Delegation grant is used to get a short-lived access token which contains the tenant, organization, and roles of the user that initiated the action. When minting the token, permissions are re-resolved, meaning they are revoked after the token is written. Delegated access does not have a refresh token, it's a new grant.
Vercel's authentication is simply the selection of which vendor you want to use (Auth0, Clerk, Supabase Auth) and connecting it to your application. That's okay if that's the way things go, and if it's a consumer product, there might be a specialist vendor. The difference becomes apparent later: On Blocks, each of the other services already recognizes the organizations, roles, and tenant context that your tokens contain. Each integration must be learned on an assembled stack.
Data and files
In Blocks, you create a schema as JSON with the CLI or in the visual editor, and the platform creates CRUD endpoints and a GraphQL API for it. App code is as follows:
const students = blocks.data.collection("Students");
const rows = await students.list({ pageNo: 1, pageSize: 20 });
const graph = await blocks.data.graphql({
query: "{ students { items { itemId firstName } } }"
});All files are subject to the same service: presigned uploads, versioning, trash and restore, sharing with ACL. This can be changed without impacting the app code, as it is a configuration decision, Azure Blob, S3-compatible storage, or SFTP. If you prefer to have your own MongoDB, specify your own connection string in the data layer for the managed default.
On Vercel, vercel install neon will install Neon and set the credentials into your environment. The order is the command that is in charge of procurement. Your schema, your api shape, your access rules are your own, the same applies to Redis, blob storage and queues as well. The marketplace approach provides choice of vendor. The decision has been made and it's configuration that you are able to amend.
The services that arrive in the box
A quick list of other things what ships as a platform service on Blocks, aside from ‘install something' that don't exist in Vercel:
Workflow automation – Visual canvas, webhook and scheduled triggers, workflow versioning. Popular email templates and mailbox history in transactional email. Notifications that are sent in real-time and have an in-box per user. Localization (glossaries, AI translation suggestions) without redeploy. Subscription, entitlements, and Reconciliation payments with Adyen. PDF generation. Magic links. Incident Response Time monitoring and alerting.
All of these are readily available on their own. They are all subscriptions, credentials, and other places where tenant isolation is your responsibility and not theirs.
The niche: multi-tenant business software
That's where Blocks shines, and to the point:
Multi-tenant software means your customers are companies. Each company receives their own workspace, their own users and ensures that no request made on company A will be processed on company B. Tenancy is the backbone of Blocks. Each request includes tenant key (x-blocks-key header), the service framework checks it, data is tenant-scoped under it and tenant groups within an organization have roles and permission grants. Delegated tokens are used to implement background workers, which maintain the tenant and organization context of the user who initiated them. There is an organisation switcher pre-installed on the SDK.
Vercel's multi-tenancy is application-layer based. You implement it in every query, every row, every cache key, or you give it to a vendor and then you replicate the tenant boundary in your data layer yourself. The platform has no idea of what's called a tenant.
The effect compounds. The tenth tenant-aware service is free on Blocks as the context goes with the request. Assembled stack – 10th integration – is the 10th integration having 10th wrong.
Shipping code
Vercel integrates with GitHub, GitLab or Bitbucket, builds on every push, and provides a preview deployment for each pull request, and if you need to roll back, it's a click away. This is still the standard for frontend delivery.
Build and deploy to Kubernetes from push webhooks or on-demand, browse into GitHub repositories and branches from Blocks Release, and let's build using Tekton pipelines. Build and deployment logs are pushed to the browser using SignalR. Security scanning is performed in the pipeline: SonarQube SAST, Dependency-Track SCA for containers and libraries, DAST. Secret values are never displayed, and are stored and retrieved with lock, unlock, and audit trails. The machine is heavier than it used to be and it's doing a heavier job, that's what auditors ask about.
Running it yourself
Blocks-infra is the whole platform as a docker-compose stack in 3 profiles: infra (including redis, rabbits, mongo8, with automatic seeding), apps (web apis + background workers), edge (nginx-proxy + acme-companion, which provision letsencrypt certificates for every service subdomain). If the DNS service is configured to receive wildcard names:
docker compose -d -p infra -p apps up -d.One variable in .env is used for pinning Versions. The end product is the same platform, on your hardware, in your region, behind your firewall.
Vercel is a hosted service. There is no self-hosted Vercel, there's no appliance to enable a customer's VPC, there's no way to bind the entire delivery stack to a jurisdiction. If your buyer is a bank, insurer or hospital or any contract with data-residency clauses, this comparison ends there.
Where Vercel wins
The frontend experience. Framework auto-detection, instant previews, rollback, and an edge network Blocks does not match.
Source control breadth. Blocks Release supports GitHub. Vercel connects GitHub, GitLab, and Bitbucket.
Choice of building blocks. On Vercel you pick your Postgres vendor, your Redis vendor, your auth vendor. On Blocks the managed default is what the platform runs on. Teams with strong opinions prefer the marketplace.
Ecosystem and hiring. More developers have deployed on Vercel than will ever have heard of Blocks, and community answers, templates, and plugins come with that. Small projects that sit idle also cost less to keep running there.
How to choose
Pick Vercel when the deliverable is the frontend: sites, storefronts, docs, and JS-heavy products with thin backends assembled from best-of-breed services.
Pick Blocks OS when the deliverable is a multi-tenant business system: B2B software, internal enterprise platforms, anything with SSO, organizations, and invoices, anything sold into regulated industries where the platform itself must run on infrastructure you control.
Plenty of teams will end up running both, Vercel for the public site and Blocks for the system behind it.
To try Blocks:
npm install -g @seliseblocks/cli-os@latest
blocks login
blocks new web my-app --blocks-key <key> --app-domain https://<your-app>.seliseblocks.comThe service repos are open source under the SELISEdigitalplatforms organization on GitHub, and blocks-infra contains the compose stack behind the self-hosting section above.