We move your Lucee, ColdFusion or PHP application from classic hosting into containers without rewriting it. That lets you rebuild, update and relocate the environment. Security updates for PHP 8.2 end on 31 December 2026 (As of 2026-10).
Docker for existing Lucee, ColdFusion and PHP applications
We move running applications into containers without rewriting them. The environment is then described in files that live in your repository, and it can be rebuilt on any suitable Linux server. We test new versions alongside production, and the way back stays open.
- Docker for Lucee, Adobe ColdFusion and PHP
- Full stack and DevOps since 2012
- Reply within one working day
Where we use Docker
We use Docker for applications that are already running, on Lucee, Adobe ColdFusion or PHP. Their environment has often grown on one server over the years: web server, runtime, extensions and settings that nobody wrote down. In a container this environment is described in files, and your team or another provider can rebuild it.
Our engineers work with Docker and also run the Linux servers underneath. The page From hosting to containers describes the move away from classic hosting and the cases in which it is not worth it. Servers, updates and security are covered under Linux & DevOps. If your applications still run on physical servers of their own, we check what fits into a container and what is better kept running as a virtual machine on Proxmox.
Typical tasks with Docker
- Inventory of the existing environment: versions, extensions, web server settings, scheduled tasks, files, mail sending and databases.
- Images for Lucee, Adobe ColdFusion and PHP with web server and settings, described in files in your repository.
- Compose files that record which containers belong together, such as the application, the database and scheduled tasks.
- Data outside the containers: database and uploaded files in persistent storage, with backups and a restore test.
- Identical environments for development, staging and production from the same description.
- Updates of the runtime and the base image, tested on staging first.
- Operation of the containers and the Linux server underneath, with a runbook for your team if you wish.
Updates with tests and a way back
An image contains the runtime in a fixed version, for example PHP 8.4 or a specific Lucee version. For an update we build a new image and test it on staging with a copy of the data. Only then do we replace the container in production, in a maintenance window agreed with you. The previous image is kept, so the way back to the old version stays open.
Security updates do not reach a running container by themselves. The image is rebuilt on an updated base, and the Linux server underneath needs its own updates. The runbook records who does this and when: your team, another provider or us.
Technologies and scope
| Area | Scope |
|---|---|
| Containers | Docker and Docker Compose for Lucee, Adobe ColdFusion and PHP |
| System and virtualisation | Linux with Debian and Ubuntu, KVM and Proxmox |
| Web servers | Nginx and Apache |
| Databases | MySQL and MariaDB, also with Galera |
Typical starting points with containers
-
-
Support for Debian 11 ended on 31 August 2026, and for CentOS 7 on 30 June 2024 (As of 2026-10). We will upgrade your server, or plan and carry out the move to Debian. We also work with Proxmox VE 8 and with physical servers that we move to Proxmox.
The first step: Legacy review including container suitability
Legacy review
For companies with a system that nobody knows well any more: before an update, before a migration or when changing service provider.
- Inventory of versions and dependencies
- Map of application, database, server and email
- Risk register covering security, support and knowledge
- Assessment of backups and restores
- Recommendation “stay, upgrade or migrate” with an options matrix that also covers “move into a container” and “expose as an API”
- Effort estimate in days
The price covers one system, meaning one application with its database and its server. We price further systems individually.
What the result contains
A written report with inventory, risk register, recommendation and effort estimate. The report is yours.
A project in containers
-
A photo upload app for wedding guests
Wedding guests scan a QR code, open one secret address and upload photos and videos straight from the phone: no app, no account, no login. Files of up to 5 GB land on the client's own disk, and the couple watches the gallery fill up during the party. One evening, no second chance, and phones from six years back.
-
A shop flooded by bots that looked like customers
A WooCommerce shop with 52 products loaded slowly or not at all. The cause was a paid network of bots sending tens of thousands of requests an hour, each from a different home address, and every single bot behaved perfectly. Our engineers stopped the traffic at the edge of the network, and when the bots changed tactics a month later, the second rule took the load off within two minutes.
Questions about Docker and containers
What do we gain by moving to a container?
An environment that can be rebuilt. The same version and configuration apply on the developer's machine, on staging and in production, recorded in the repository instead of in one person's head. We test new versions of PHP, Lucee or ColdFusion alongside production and can roll them back. Moving to another server or another provider also becomes easier.
A container fixes no bug in the code and does not bring an unsupported version up to date. It only makes those changes easier.
Does my application need changes for the container?
As a rule, the application's logic stays the same; the environment and configuration change. Exceptions are things tied to the old server. Examples are absolute file paths in the code, sessions stored on the local file system and services expected to run on the same server.
We record this in the inventory and tell you before the work starts what has to be adapted.
What happens to the database and uploaded files?
We treat both separately from the application. Data should survive a restart or the replacement of a container, so it lives outside the container. The database runs on its own server or in a separate container with persistent storage, and uploaded files sit in a mounted directory.
In the inventory we define where everything lives and how it is backed up. Before the switchover we check that both can be restored from the backup.
Can Adobe ColdFusion also be run in containers?
Yes, Adobe ColdFusion can run in containers. In the legacy review we check whether your installation is suited to it.
Do we have to change our hosting provider for containers?
With conventional shared hosting, Docker usually cannot be used. You need a server on which you can install software freely, for example a virtual server.
Whether your current package allows this or a change is needed, we clarify in the legacy review. You can run the server with a provider of your choice, and we set up the containers there.
Who runs the containers after the move?
That is your decision. With the runbook, your own people or another provider can operate and update the containers themselves.
If you prefer, we take over operations as part of Takeover and maintenance and Linux operations and infrastructure.
Not sure which service fits your system?
Describe your system in two sentences. We will tell you which service fits and whether an entry product at a fixed price is the right first step.