3 Subdomains, 1 Azure Database, 1 Vercel Frontend: How I Split agenticai01.tech

Most Next.js projects are monolithic: one repository, one Vercel deployment, one Supabase database. This is the right default. Do not add complexity before you need it.

agenticai01.tech needed to be split. Here is why, and how the split is structured.

Why Split at All

The three surfaces of agenticai01.tech have genuinely different infrastructure requirements:

Marketing and discovery (root domain) — Needs CDN-level performance, full static generation, and zero database dependency for the initial render. A dynamic database connection would add 50–200ms to every page load. Static Next.js on Vercel is optimal.

Application layer (app subdomain) — Needs Supabase Auth, dynamic user-specific data, real-time agent status updates, and server-side rendering for authenticated routes. Cannot be statically generated.

API and execution layer (api subdomain) — Needs long execution timeouts (agent runs can take 30–120 seconds), CPU isolation between runs, and direct database access without going through a frontend proxy. Vercel's edge functions have a 25-second limit. Azure Functions on a consumption plan allows up to 10 minutes.

If I put all of this in one Vercel deployment, I would be fighting the platform constraints for the API layer. The split matches infrastructure to requirements.

How Each Layer Is Wired

Root domain — Static Next.js exported to Vercel. No database reads at build time beyond generating the list of featured agents. Deployed independently from the application layer.

app.agenticai01.tech — Separate Vercel project, same GitHub repository, different build target. Connects to the Azure PostgreSQL database via a connection string stored in Vercel environment variables. Supabase Auth manages user sessions — the auth layer runs through Supabase's hosted auth service, but the application data is in Azure PostgreSQL, not Supabase's PostgreSQL.

api.agenticai01.tech — Azure Functions, Node.js runtime. Each function is invoked via HTTP. The agent runner, webhook processor, and payment handler live here. Connected to the same Azure PostgreSQL database.

Cross-Domain Communication

The application layer triggers agent runs by calling the API layer:

// app.agenticai01.tech — trigger an agent run
const response = await fetch('https://api.agenticai01.tech/agents/run', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${serviceToken}`,
  },
  body: JSON.stringify({ agentId, input, userId }),
});

The service token is a shared secret between the application layer and the API layer — not a user-facing token. It is stored in Vercel and Azure environment variables respectively.

CORS is configured on the API layer to allow requests from app.agenticai01.tech only.

The Database: Why Azure Instead of Supabase

The question I get asked most: why not just use Supabase for everything?

Two reasons. First, the agent execution data has compliance considerations that made a dedicated managed PostgreSQL instance preferable to a shared Supabase project. Azure Database for PostgreSQL (Flexible Server) gives a dedicated, isolated instance.

Second, Supabase's free tier allows one project per organization. I was already using Supabase for santoshpaudel.me. A second Supabase project would require a paid plan or a second organization. Azure PostgreSQL on a Flexible Server Basic tier costs approximately $13/month — not free, but predictable.

When This Split Is Wrong

For most projects, it is wrong. A monolithic Next.js app with Supabase is simpler to deploy, debug, and maintain. The split for agenticai01.tech is justified by genuine execution time requirements (the 25-second Vercel limit) and genuine isolation requirements (the API layer handles financial transactions and should not be co-located with the marketing site).

If your project does not have these specific requirements, do not split. One Vercel deployment, one Supabase project, one mental model. Complexity has a maintenance cost that compounds over time.

---

Resources

• —Azure Functions — consumption plan — the plan used for api.agenticai01.tech; timeout limits, cold start behaviour, and pricing
• —Vercel environment variables — how to store the cross-domain service token securely across Vercel and Azure
• —Next.js multi-zone documentation — an alternative pattern for multi-subdomain Next.js apps within one Vercel team

Related Posts

• —Inside agenticai01.tech: Building an Agent OS for the Web3 Era — the full product context behind this architecture decision
• —The New Solo Dev Stack: What Replaced a 5-Person Team in 2026 — when this architecture makes sense and when a simpler monolith is better
• —How I Structure a Supabase + Vercel Admin Panel From Scratch — the admin panel pattern that the application layer (app subdomain) uses

---

Building a platform with complex multi-layer requirements? I architect and build multi-subdomain systems across Azure, Vercel, and Supabase. See my work or get in touch.