PaaS, Coolify, Terraform and AI: How to Manage Your Infrastructure in 2026 When Launching a Startup

I created my first company which went well 14 years ago and I was able to grow that company from 0 to over 700 employees.

You can imagine that the constraints when starting, the working methods, the tools, are very different from what you might encounter in most companies you know. You don't work the same way at 0 and at 700.

You need to be fast, you need to build an application that people want to use without burning mountains of money you haven't earned yet and it's for all these reasons that I chose not to take care of the entire software infrastructure part at the beginning. What I call infrastructure is the servers, databases, backups, everything that's invisible to most people but essential for an application to function.

It's essential, but overall everyone doesn't care about it. It's not that which allows you to sell a product. Good infrastructure but with a bad application doesn't work. And if you spend too much time on infrastructure, you don't make a good product. Obviously it still needs to work but you can delegate it, I would even say you should delegate it. Infrastructure should be a non-issue for several years when you start.

So back then I chose to use a PAAS, a platform as a service, which precisely allows you to delegate all the infrastructure to people whose job it is. And whenever I saw people starting companies but starting to tell me about Kubernetes or Docker, I would systematically tell them it was far too early to talk about that. I always saw that as a bad signal whenever someone spent their time explaining to me how they were making their product, not what product they were making. The nuance is important.

Now, I'm changing my mind. Except for Kube. I just launched a new product, Kula, the world has changed, company creation has changed and it might be time to reconsider some choices.

So we're going to talk about PAAS, coolify, dokploy, easypanel, terraform, AI and how we can deploy applications in today's world.

PAAS or not PAAS

In 2014 I wrote an article on exactly this subject (in french). Because in 2014 we were leaving Heroku, our PAAS at the time to go to an OVH server.

A PAAS is, in very simplified terms, an execution environment that allows you to run your applications. A PAAS manages for you web servers, databases, backups. It should allow you to collect and analyze errors that occur, alert you if you're running out of memory or CPU.

We left Heroku because in 2014 we were starting to hit the limits of what PAAS could offer. Among the important limitations I could mention:

• There was no notion of private network. A private network is what allows your application to communicate with a database without going back through the internet. So the database is only accessible within your network. Most PAAS offerings didn't provide that.
• There was no notion of web frontend. A web frontend is a server that we place in front of one or more applications. This allows, among other things, to have different applications that are used for different parts of a website.

In 2014 with Malt we needed precisely to be able to route Web requests to several different applications. For example the /search page was a separate application from the one that served the /profil page.

Despite everything, in hindsight, it was a dangerous choice. The company was only 2 years old and I had to do a lot of ops to reproduce a satisfying developer experience on OVH. That's time I didn't spend elsewhere. Fortunately I already had experience on the subject and good mastery of certain automation tools like Ansible which limited the damage. But it was also an economic choice. A PAAS could quickly become expensive. Each resource (a database, a server, a process) is billed independently. And in 2014 at Malt, I can tell you we counted every euro spent very carefully.

Okay, but I'm talking about Malt in 2014. Then the company grew well, we doubled in size every year. In 2017 we hired our first ops. We started doing OVH Cloud. In 2018 we went to GCP and we were no longer off by 100 euros. But that's not today's subject. What interests me is the startup phase.

Self hosted PAAS

Since 2024 I left Malt and started creating products again. I love doing that. I find the first steps exciting. You have to know how to deal with constraints, be creative.

I first launched Broadcast in 2024, a newsletter sending service for static blogs. Then Pulse in 2025 while I was living in Japan, an analytics service for blogs. Connect in 2026, a comment as a service (like Disqus). Writizzy in 2026 as well, a blogging and newsletter platform, a competitor to Substack or Beehiiv. Until now, it was the most ambitious and largest project.

And for all these projects I used a new range of tools that I discovered in 2024, self hosted PAAS. They are PAAS, but they are PAAS that you can host yourself.

I chose Coolify, which I already talked about in an old article.

First of all, obviously, that changes the price. Today I run Coolify on two machines, with all my applications, all my databases. That represents more than thirty resources and it costs me 45 euros per month. Remember, I'm back in startup mode, so with very little money and it's therefore a heavyweight argument. No commercial PAAS can allow me to run all these resources for that amount. It would be at minimum between 300 and 1000 euros per month.

I lose time on it, I have had some cold sweats with system updates, connection losses, machines that break down. But the fact of using a PAAS, so software that takes care of all deployment, monitoring, logs is a significant gain. Even if I need to understand how it works, I'm not obligated to spend as much time on it as if I had to manage everything manually and dive into the workings of Kubernetes for example.

But, with more than 30 managed resources, I started to feel some limitations and especially, I realized that maybe, maybe I was going in the wrong direction. What if AI could become an excellent ops for me?

The Limits of My Self Hosted PAAS

I love Coolify, but there are still important limitations:

• Coolify doesn't allow multiple nodes of the same application
• There's no secret management. All environment variables are in plain text. You have to use a service like infisical.
• Monitoring exists but remains quite light.
• Backups are only in snapshot mode. That is to say you take photos of the database at regular intervals but in case of a crash, you lose all information since the last backup.
• it's clickodrome. You can hardly automate the fact of rebuilding resources, especially since the api is limited.

This last point, if you have only one application, it's not very serious. But I already have too many applications. If I need to bring up an entire server, I'll have to reconfigure everything and I really don't want to. I'm exaggerating, Coolify's database itself is backed up in snapshot mode but it's a bit more painful and it doesn't allow me to easily migrate to another service, like Dokploy or EasyPanel.

So I tested something else. I asked AI…

AI-Ops

Yes, ops takes time, it can be complex and you can't mess up. But writing code that allows you to automate your infrastructure, your network topology, your backups, your observability, that remains an excellent idea, much better than making dozens hundreds of clicks on an interface.

Because code can be versioned. And I'm telling you that, I've already done Ansible, Capistrano and shell batches, so I'm not discovering that in 2026. But I also know that writing code is long and once again, it's time you don't spend on the product. Except… if AI writes it.

In October 2026 I decided to take advantage of the experience I acquired on Writizzy and Broadcast around email sending to launch another product: Kula. Kula is a marketing and transactional email sending tool. I manage sequences, segmentation, analytics tracking, deliverability management and it's now the email sending backend for Writizzy and Broadcast. If you're already a customer of sendgrid, mailjet, brevo, or resend, don't hesitate to test. Plus I'm generally cheaper.

Except this time I didn't want to use Coolify again for Kula. So I used AI to create Terraform scripts to control my infrastructure (at Hetzner, Bunny.net and AWS). I added continuous deployment, rolling upgrades with Caddy, incremental backups with WAL, logs collected in dozzle. And all that took me less than 1 hour to set up.

I can bring up my entire infrastructure more easily, I manage and version my secrets with Sops, I lowered my RPO from several hours to 1 minute (RPO is the maximum possible data loss) and I can control everything from my code, by running scripts. Finally, my LLM can control everything.

Now, if you didn't understand RPO, Sops, WAL, rolling upgrade and overall what I just said seems as clear as Chinese to you, it's because I may have misled you…

AI Only Accelerates What You Already Know How to Do

In reality I haven't totally changed my mind. I still believe you should delay ops as late as possible but with much more nuance than before.

You do ops anyway, even with a PAAS, but a large part is simplified, pre-digested for you. Except that precisely, you delegate choices to people who know how to do it without always understanding the compromises they made for you. You hadn't necessarily understood before now that your backups were imperfect. You hadn't perhaps realized that your secret management was a mess before I mentioned it to you.

Creating IT projects is constantly making compromises between costs, risks and gains. And you can't maximize all three. Low risks and many gains requires a lot of budget. Low budget to get many gains, it's necessarily because you're taking risks. Etc… It's not a problem to solve, these are choices to make.

So if you lack general knowledge, if you decide to do everything directly with AI, it might send you crashing into a wall because you won't understand the compromises that were made. It's true, there's no longer as much argument about loss of time as before. You can go very fast. But going fast into a wall isn't necessarily an advantage.

In my case, I wasn't starting from scratch, far from it. So I knew where to go. I was already doing ops by choosing to use Coolify in self-hosted mode and then I had some experience, including in much larger companies. I understand the compromises I'm making.

When I say that I launch a new company using terraform, I'm taking a shortcut. I've been launching products since 2011. And since leaving Malt, I have 2 years under my belt with Hakanai, Writizzy and Kula. When I say I took 1 hour to set everything up. It's true, but I took 25 years to learn to set it up in 1 hour.

So let me rephrase.

If you have no knowledge or experience of ops, infrastructure, take a PAAS. A very simple PAAS that you don't host yourself (Clever Cloud, Scalingo, Sevalla for example).
The cost will remain acceptable and you'll have the opportunity to learn on a stack that's managed for you.
(I came across koyeb too while writing the article but I'm having trouble positioning it between PAAS and IAAS, don't hesitate to give me info if you know)

If you have knowledge but you're still in prototyping phase with still few applications to manage, choose a market PAAS or a self hosted PAAS, Coolify, Dokploy or EasyPanel. Here you'll prioritize cost and flexibility.

If you're really knowledgeable, you can go to dedicated servers controlled with terraform. It's the advanced version of the previous option, focused on cost and flexibility.

As soon as you have volume, and several applications, some architectural complexity and a budget to finance it, then you can start looking at IAAS (infrastructure as a service), DBAAS etc… I recommend Scaleway or Hetzner.

In short, it's hard to launch a company. It's even harder to learn all the necessary trades at once. Even with AI. Don't waste time on what you don't yet know how to do. However, as soon as you've gained the experience, tell yourself that many things that were very time-consuming before is now much more accessible. Revisit your preconceived ideas on the subject and test. You might be surprised.