Coolify v4.5 Update: Changes in Docker Deployment and Self-Hosted PaaS
Coolify has established itself as a leading open-source Platform as a Service (PaaS) for developers looking to reduce cloud costs and directly control container-based services on a single server. The recently released Coolify v4.5 includes several practical changes that enhance the stability of Docker deployment pipelines and improve container management and self-hosted development environments.
The most notable policy change in this update is the restriction on replica settings in Docker Compose. Additionally, official Gitea integration has been added for developers who prefer independent repository environments, and security measures for container build systems and API tokens have been tightened.
Blocking Multi-Replica Docker Compose and Container Rollbacks
Starting with Coolify v4.5, deployments will be rejected if the Docker Compose file contains scale or replicas settings greater than 1. This measure is intended to fundamentally prevent multi-container configurations that cause proxy routing and port conflict issues in single-host infrastructures, ensuring stability focused on single-container instances.
Along with this, a rollback feature has been officially introduced to immediately revert to the most recent Docker image stored in the registry. If a runtime error occurs right after deployment, you can quickly restore the service by referencing the previous image tag without having to rebuild. A docker attach feature—an interactive console mode—has been added to the container terminal, making it easier to check the internal state of a running container in real-time.
Gitea Integration and Transitioning Default Buildpacks
The range of private repository support has also expanded. In addition to existing webhook integration for GitHub and GitLab, users can now register official Gitea app sources to automatically fetch and deploy code from Gitea repositories installed on personal servers. This is a useful change for teams building closed networks outside the cloud or independent self-hosted server infrastructures.
Changes have also been applied to the container image build tool ecosystem. The long-used Nixpacks buildpack is entering a deprecation phase, and Railpack has been designated as the officially recommended tool. A smart scan feature that automatically detects and analyzes Dockerfiles and environment variables when a project is first registered has also been added, streamlining the project creation process.
Stricter API Permissions and Server Security
The API token permission system used to control Coolify via automation scripts or CI pipelines has been refined. Previously, basic tokens allowed for broad control, but now only tokens with explicitly granted deployment permissions can trigger server-side effects like executing scheduled tasks, changing proxies, or deleting resources. Backup execution messages and sensitive information have also been isolated, ensuring they cannot be accessed with basic read-only permissions.
In terms of server operations, a server patching feature has been added in beta, which automatically applies OS security patches and alerts you in the server list if there are risky packages or a need for a reboot. Logic to automatically back up the internal database before performing Coolify updates is also applied by default, reducing the risk of data loss due to update failures.
Which Environments Are Suitable and When to Avoid It
Coolify v4.5 is suitable for full-stack developers looking to easily manage web applications, databases, and backups on personal VPS or single physical servers. Even if you aren't familiar with writing Dockerfiles, you can immediately enjoy the benefits of Railpack-based automated builds, automatic SSL certificate issuance, and intuitive container rollbacks.
It may not be suitable for large-scale production environments that require distributed container placement across multiple servers or sophisticated orchestration at the level of Docker Swarm or Kubernetes. You should inspect your Compose structures beforehand, as migration of existing projects that relied on load balancing via scale settings in Docker Compose files may result in deployment rejection errors.
