Why I Moved My Personal Projects from Laravel Forge to Coolify
Learning and coding with PHP might be easy but it is not the same for deploying them to production environment. First of all, you have to…
Why I Moved My Personal Projects from Laravel Forge to Coolify
Learning and coding with PHP might be easy but it is not the same for deploying them to production environment. First of all, you have to set your server environment. These are generally:
- installing php-cli, php-fpm (or php-fastcgi)
- installing php extensions
- maintaining php.ini config file
- setting a reverse proxy (nginx)
- managing php-fpm, queue, daemon workers
- struggling with multiple php versions for multiple apps
Even though most of these tasks are boilerplate, your project will not work correctly if any of them is missing. What’s next?
We need to deploy our code to server. We have to manage how we deploy the code. You can write some deployment scripts with bash, store them in VCS or your PC, run the script whenever you want. But what if you want to run database migrations after each deployment? In this case it is much more than copying the code to the server. Your deployment script must be run in the server so you can write a script like this:
cd /path/to/project
git pull origin main
php artisan migrate --force
# restart php-fpm process etc...
Laravel Forge
Let’s meet with Laravel Forge. It’s a paid server management SaaS by Laravel core team. Once you connect your server to Laravel Forge, it sets your server up, installs all necessary things to run a PHP (or web) app, handles OS updates and security, has native support for first party laravel packages (horizon, reverb, octane, etc.) and a dashboard where you can manage your servers, deployments, settings, etc.
It sounds cool, doesn’t it? If your organization has small teams, and does not have a separate devops team, it is a perfect fit for you. In Laravel forge;
- you can grant access by role for any team member
- good implementation of the websockets in the dashboard
- you can manage multiple servers
- every operation has an audit log so you can debug when things go wrong
- you do not have to do boilerplate things
- easy deploys with several clicks
- configurable deployment scripts
- good set of integrations such as slack, infrastructure providers (aws, digital ocean, hetzner etc.), sentry, github, gitlab etc.
What they aim for is same with the Laravel framework. Let developers focus on developing, not on something else. They should not be aware of how servers work but they should step in whenever they want. So far so good. But this is only one side of the story. I use Forge every single day, and almost every day I deal with an operational problem caused by it. Everything was fine for a while, until they released Forge v2.
The new version brought fresh new UI with many more bugs. I’m not against innovation. I’m against adding lots of features nobody else will use all at once and changing the dashboard UI to more complex one. Here is the list of problems that I encountered after the v2 update. I put them into three groups, because they are not the same kind of problem.
The v2 release was not ready
These bugs show that the new version was shipped too early:
- The server transfer feature was not working, so I couldn’t transfer our client’s project to their organization.
- The contact support feature was not working (console error in the browser), so I had to find Forge’s support email, which was not easy at the time.
- Search indexes were incomplete, so there was no search feature for a while.
- Permission errors have recently started occurring with the GitLab integration.
- Auto deployments are not working from time to time, so we have to trigger them manually.
- After v2, we started to see downtimes, especially after forge released the managed database feature.
The state lives in Forge, not on the server
This is the group that made me think the most. Forge keeps the state of your server in its own database, not on the server itself. When Forge’s state and the real server do not match, you get stuck. Here is what I mean:
- Sometimes the state of domains, SSL certificates and deployments got stuck in an inappropriate state (pending, provisioning) and this blocked my whole day. The server was fine, but Forge thought it was not.
- When I first enabled the zero downtime feature for an Octane project, there was no protection for it. Octane already runs without downtime, but Forge still kept every deploy as a separate release folder on the server. They fixed this behaviour later, but there was no migration, so the old broken state stayed as it was.
- When there is a network partition between Forge and the server, we simply cannot manage the server anymore. Forge connects over SSH, so if the connection is gone, the control is gone too.
All of these come from the same root: Forge holds the state and the control outside of your server. The connection between them becomes a single point of failure.
Forge is built for web apps only
- I was once asked to set a DNS record for a worker server that doesn’t even have NGINX installed. Other server types (e.g. worker servers) were obviously not tested properly. The UI is designed for web apps, and it breaks on the other server types.
I use Laravel Forge both in work and my personal projects. I take an active role on provisioning servers, setting up projects, writing deployment scripts, setting up firewall etc. As organization, Forge is still our favourite server management tool because there is no better alternative that we can use as organization. But for my personal projects, I found that there is no reason to pay for Forge every month.
Coolify
On the other hand, there are some open-source server management tools. Coolify is one of them.
Compared with Forge, Coolify has totally different approach for managing your servers and deploying your projects. To make comparison;
- Coolify’s source code (and database) lives on your server while Forge uses SSH connection to manage your server
- Forge handles security (fail2ban, ufw, separate linux user) on your behalf, Coolify documents how you can do it
- Coolify requires Docker to deploy, and uses nixpacks to dockerise your app while Forge uses php-fpm & nginx to serve your applications
- Forge is a product for PHP and webapps, Coolify is universal
These are the main differences between them. Coolify requires slightly more effort to go on but does not limit you to PHP.
Why good?
Let’s talk about some features that Coolify has but Forge hasn’t.
1 — It has a pre-configured services that you can install with several clicks such as databases, keycloak, gitlab CE, wordpress etc.
2 — You can create different environments for same project (prod, stage). Also PR previews are supported. Once you open a PR, you have a generated preview link.
3 — You can access any container’s shell from the dashboard.
4 — You can rollback to previous deployments easily.
5 — You can do everything that Forge can do and it’s free :)
Why not for everyone?
Coolify is great, but it is not for everyone. I want to be honest here, the same way I was honest about Forge.
- You must know much more about Linux, deployment strategies, Docker and optionally nixpacks. There is a learning curve.
- Forge handles security for you (fail2ban, ufw, a separate Linux user). With Coolify you have to do these yourself, Coolify only documents how.
- Coolify does not have the team features that Forge has. There is no role based access or audit log, so for an organization it is harder to use.
- Coolify itself lives on your server. This is good for network partitions, but it also means you have to maintain it. If Coolify breaks, it is your job to fix it.
- It is a younger product, so sometimes you find less documentation or fewer answers than Forge.
Still, none of these stopped me. I encourage you to just create a $5/month server, install Coolify and try to deploy some projects. It only took me 1 week to understand how things are done, and AI will be your best assistant during learning.
Conclusion
So, should you move from Forge to Coolify? It depends on you.
If you work in an organization, with a team and different roles, Forge is still a solid choice. The role management, the audit log and the team features are hard to replace, and this is why we still use Forge at work.
But if you are a solo developer, or you work with more than just PHP, or you simply do not want to pay every month, Coolify is worth trying. You get more control, you are not limited to one language, and it is free.
For me the answer was clear. I moved all my personal projects to Coolify, and I do not regret it.
Thanks for your time. Please do not hesitate to ask any questions, take care.
메타데이터
- post_id
- 354efb2eded1
- slug
- i-replaced-my-laravel-forge-managed-server-with-coolify-here-is-the-reason-354efb2eded1
- url
- https://medium.com/@aknevrnky/i-replaced-my-laravel-forge-managed-server-with-coolify-here-is-the-reason-354efb2eded1
- canonical_url
- https://medium.com/@aknevrnky/i-replaced-my-laravel-forge-managed-server-with-coolify-here-is-the-reason-354efb2eded1
- author_url
- https://medium.com/@aknevrnky
- status
- ok
- fetched_at
- 2026-08-28 08:19:09