How to combine Vercel with a backend and PostgreSQL on ArduMaker

Published on 2026-10-26 by frfrand

Frontend Vercel and Django or FastAPI backend with PostgreSQL on VPS

This is an architecture I like because it doesn't force you to pick a side: you use Vercel for the user-facing part and an ArduMaker VPS for the API, PostgreSQL, and processes that need to stay active.

There is no universal winner. If we only compare the lowest price in the catalog, the conclusion is usually false: an API with a database, workers, files, and multiple clients does not cost the same as a static page.

The fundamental difference between Vercel and ArduMaker

Vercel: Vercel builds and distributes the frontend, including its preview and execution-compatible features.

ArduMaker: ArduMaker runs the backend and the database on a VPS, with supervised processes, domains, and access to the server environment.

A real project to compare them without guessing

On a booking platform, the visitor sees a fast Next.js app; the API checks availability and confirms an operation within PostgreSQL. A worker sends an email after saving the reservation. None of those processes need to run in the browser.

Instead of deploying two separate demos, I chose a single repository and applied the same load. If one uses an external PostgreSQL and the other a local database, note that difference so as not to attribute all latency to the web provider.

Practical test in five steps

1. Deploy Next.js on Vercel and verify that the build does not contain private secrets.
2. On ArduMaker, deploy FastAPI or Django from Git and configure PostgreSQL with restricted access.
3. Publish api.tudominio.com with HTTPS, without opening the PostgreSQL port directly.
4. Define the API URL in the frontend and configure CORS only for authorized origins if needed.
5. Test login, cookies, token renewals, file uploads, and a backend error.

Don't forget to test the error path: stop the process in a controlled window and see if the system shows you why it stopped responding. If an application records reservations, also test two simultaneous requests to verify the availability and consistency rule.

The typical mistake when comparing

Do not use localhost:8000 as the API URL in production and do not enable CORS with any origin and credentials without understanding its risks. Also keep cookie domains in mind.

I wouldn't just look at the "yes" and "no" boxes in a table either: ask under which plan the feature is available, if it requires an external integration, if there is an execution limit, and which team will be responsible for maintaining it.

How ArduMaker fits into the discussion

ArduMaker hosts the persistent part and provides Git tools, services, database, domain, and MCP. Vercel continues to fulfill its role as frontend. This combination takes advantage of different benefits without duplicating them.

For an architecture that combines FastAPI, PostgreSQL, and a worker, in ArduMaker you can create the VPS, associate the Git repository, manage the database and the process, and publish the domain with HTTPS. If you have a frontend on another platform, you can also keep it there and move only the API. You don't need to migrate everything to take advantage of a concrete benefit.

Which one would I choose to work with every day?

This architecture can be better than moving everything to a single site if your team enjoys Vercel's previews but needs its own backend processes.

I would make the comparison with the project I actually have to deliver, not with the shortest tutorial. Before changing providers, save and verify backups, prepare the rollback, and calculate how much time maintaining the new configuration will cost you.

Sources to verify current details

• Vercel Documentation
• ArduMaker Documentation
• Compare Vercel with ArduMaker

Summary: what matters is not only how the first version is published, but who can operate it, recover the data, and solve a problem at three in the morning.