How to publish a FastAPI API on Render step by step

Published on 2026-10-26 by frfrand

Publish FastAPI on Render with Git, variables, service health, and VPS alternative with ArduMaker

You made an API with FastAPI, tested /docs on your machine and now you need someone else to be able to book an appointment. Render allows you to turn that repository into a web service. But there are several details that matter more than the Deploy button.

I'm not going to sell you the idea that one platform is perfect for everyone. What's useful is understanding what work it saves you, what work is still yours, and how much it can cost to maintain it when the project stops being a test.

Render: what it really offers you

Render offers managed web services, jobs and databases, with an abstraction that avoids administering many system tasks. The plan and service type determine resources, availability and persistence. Don't confuse an HTTP process that handles requests with a task that processes emails continuously.

An example you could have tomorrow

On a tours website, FastAPI receives the date of a reservation, PostgreSQL checks availability and a worker sends the confirmation. The API should not send the email during a request that needs to respond quickly. Separate those responsibilities and look at the cost of all the necessary services.

How to get started without overcomplicating things

1. Push FastAPI to GitHub and declare dependencies in requirements.txt or in your chosen package manager.
2. Create a Web Service and associate the repository; choose the supported runtime.
3. Configure the start command, for example uvicorn main:app --host 0.0.0.0 --port $PORT, adjusting the module and ASGI object.
4. Load secrets via environment variables and connect to PostgreSQL using private credentials.
5. Define a health route and test from outside the service a real write and read operation.

The fifth step is often the one that gets skipped: open the application from another device, execute an operation that writes data, check a log, and verify it again after restarting. That is worth more than a screenshot where the panel says "deployed".

The mistake to avoid

A green deployment does not guarantee that the API can connect to the database. If a 502 appears, check the start command and the port; if a 500 appears, investigate the application logs. Avoid writing important files to ephemeral storage.

There is another simple rule: if the project has clients or payments, do not experiment with migrations directly on the only copy of the database. Test in a separate environment, keep a verifiable copy, and prepare how to roll back.

How would I solve the same in ArduMaker?

In ArduMaker you can put FastAPI on a VPS, create the corresponding systemd service, associate Nginx and HTTPS, and manage PostgreSQL from the server environment. It is more flexible for combining API, Redis, and workers; it also requires maintenance and monitoring.

In a typical case, you could create the VPS in ArduMaker, connect the Git repository, install or manage PostgreSQL according to the application, define the execution process, and publish an HTTPS domain. If there is a worker that takes several minutes, separate it from the HTTP service. And if the project has several clients, organize them by Company to avoid mixed permissions and resources.

What I would look at before paying or migrating

I wouldn't choose based on a single figure on the pricing page. Note CPU, RAM, persistent storage, traffic, backups, support, and maintenance time. If you need to add a managed database, a workers service, or a licensed panel, include them. If you want redundancy between servers, that also needs to be designed: a VPS alone is not high availability.

So, which one would I use?

Render is worth it if you want to delegate infrastructure and operate within its service types. ArduMaker fits better when you need to configure a VPS and several processes your own way.

An honest test: publish a minimal API, connect it to a database, stop the process to see what the system logs, and try to recover it. The platform with which your team can repeat those steps without suffering is usually the one that brings you the most value.

Sources and further reading

• Render official documentation
• Comparison of Render with ArduMaker
• How VPSs work and what they are for

The final idea: first solve a real problem with the tool. Then compare how much effort it takes to maintain it. That's where the difference between a demo and an application you can deliver to a client appears.