Vercel Python and daemons, Fly and Supabase MCP. When a backend should live on your own server

At the Vercel Ship conference on October 15, Vercel announced that Python is generally available on its platform, containers run as functions, and daemons have arrived for background workers. The same week, Fly.io showed its MCP server, and Supabase explained how to give your application an MCP server of its own. The news shares one idea: the platforms want the whole backend to live with them and an agent to manage it. For a business owner the question is different: where the system will sit, what it costs per month, and what happens when the pricing changes.

What was announced

On October 15, Vercel described backends on Vercel: Python, containers and daemons on its blog. By their numbers, 150,000 teams run Python backends there, and during the container beta 5,000 teams made 150,000 deployments. Containers run as functions on Fluid compute with Active CPU pricing: waiting for a database or a model to respond isn't billed. In their example, a company called Delphi moved its Python backend from AWS ECS: ten engineers with no dedicated infrastructure person and more than 100 releases a day.

The same day, Vercel announced that Python on Vercel is generally available: the platform detects FastAPI, Flask and Django on its own and provides a Python SDK for queues, storage and models. In the same batch, Vercel Daemons went into public beta: containers that run continuously and pull work themselves from a Vercel queue, Celery, BullMQ, RabbitMQ, Kafka or a database.

On October 21, Vercel added routing middleware in Python: it runs before the main application and can rewrite a request or redirect it. And on October 23, the CLI got spend management: the vercel budgets command shows spending and the budget, and the --pause flag stops production deployments across all projects once spending reaches 100%.

On October 23, Fly.io presented the Fly MCP Server: a single MCP server through which an agent works both with Sprites sandboxes and with production Fly Machines. A Sprite is a Linux machine with its own disk, and moving to a Machine looks like moving a Linux service between two Linux machines. The post includes a number from a Databricks report based on Neon telemetry: in October 2023 agents created 0.1% of databases, in October 2025 it was already 80%.

On October 22, Supabase showed how to give your application its own MCP server. A customer of your app signs in from ChatGPT or Claude under their own account, every tool call runs on their behalf, and the RLS policies in Postgres decide what they are allowed to do. I like this part: the permissions are the same as in the application, and there is no service key.

Example: manufacturing and the bill at the end of the month

A manufacturing company calculates orders: the program walks network folders with design documentation over SMB through a VPN, checks materials against the 1C catalog, and renames files for the laser cutter. None of the platforms described above will do this: the backend has to sit inside the company network.

A budget with a pause is a useful button, but look at what it does: at 100%, production deployments stop. For a service company that means the website with the request form goes down on the day the ads brought in more people than usual. On your own server the bill is the same every month, and a traffic spike shows up in the logs.

How it works for me

The kononov.dev website and the “Coffee Together” service sit on one server with 2 GB of memory, in Docker behind Nginx. The containers have hard memory limits, during an update the old instance stops before the new one starts, and if a build runs out of memory, I build the image off the server and upload it ready. “Coffee Together” is written for the Cloudflare Workers runtime with the D1 API on top of a local SQLite in a Docker volume, so it's a platform runtime on my own hardware and on free tools.

To a car rental company in South Africa I proposed setting up their own server, because the booking and handover logic had outgrown what AmoCRM settings could do. The idea was accepted, and over 2025 the system grew from integrations into a website with a full booking cycle, an app for managers and a document chain. In every case the code, the database, the server and the access credentials belong to the client.

A platform gives you a preview of every change and a one-click rollback without an admin on staff. For a team of ten engineers with a hundred releases a day, like Delphi, that is justified. I haven't deployed Vercel Daemons, Fly MCP or the Supabase MCP block myself and go by their descriptions.

What I would do

Count a year ahead: the platform plan plus Active CPU plus daemons against server rent plus the hours to maintain it. One-off work with me costs around $80 an hour, maintenance is covered by a separate agreement, and the hours for the server need to be counted honestly in this calculation.

Write down what the backend needs that the platform doesn't give: a VPN into the local network, SMB, telephony, long-running processes with state.

Keep the Dockerfile the same for the platform and for your own server.

Build MCP access to your own application the Supabase way: calls on behalf of the user and the same permission checks as in the application. In 2023 I experimented with function calling by a model for a consulting company in London; today I would call what came out of it a prototype of an MCP server.

On the center of a system that holds state and runs the process, there is an article about the server as the core of the system. Projects from this review: “Coffee Together” and the rental company in South Africa. I cover who owns the code and the server in the review on sovereignty, the simple version, Docker Compose versus Kubernetes here, real time in the review on WebSockets, schema migrations in the review on Supabase branches and D1. I separated a heavy report from the working database earlier. Service areas: infrastructure and DevOps and an application for your scenario. If you are choosing where your backend will live, write down what it has to do, and I'll tell you what I would pick myself. Discuss your task.