Yesterday I was shocked when I heard an established TYPO3 Expert say: "Do you know this situation when you update a TYPO3 website and then the customer calls because the website is not working anymore".
Even when this guy probably doesn't have that kind of issue since he is a well known professional, and he just used that argument to promote his newsletter, this reveals a deeper and very real problem: People who setup CM-Systems often have no idea how to set up a proper dev environment or a CI/CD system!
This is not only a problem with TYPO3. It's also there for WordPress, Drupal and whatnot.
How it's often done and why that is wrong!
Even in 2025 there are "developers" out there who install a CMS via some sort of "one click installation" or just push the base code to their servers and then use the built-in extension managers/repos/stores to install extensions and templates on a live prod system without testing them first.
This can work fine for your private website, your club or your moms' recipe blog, but this definitely doesn't work for a professional company website that will lose money if it goes offline.
One just doesn't test in production!
And no, a "stage or firewall extension" doesn't make anything safer! If you're installing stuff on a live system you're still testing stuff on a live system!
How do we solve this?
By applying basic software development principles, you will (almost) never have the problem again that your live website goes down because you just wanted to "quickly check out this extension" or "just did an update"
In this blog post I'll show you the basics of how to set up a bulletproof TYPO3 environment that can be upgraded and is tested before you go live.
Local development
Since we don't want to test out stuff on prod, we need to have a local development in place. Therefore, I recommend:
- Docker
- Composer
- PHP-Storm
- Git and Gitlab
- XDebug
- PHPUnit
If you're not familiar with docker, you can also use DDEV for local development, but I'm not a big fan of that (I might explain why in a different post).
Stage
We're going to run a 3-Stage approach. First stage will be our local development, second stage will be the actual stage and the last stage is the live system.
The stage system will have a copy of the live database (if there is no sensitive data in it) and will act as our testing ground. All the settings and configurations should be the same as in the production environment.
You can have a different log level that might help with debugging
Testing
1. Automated testing
Testing is something every developer hates to do. Since we're most likely not talking about developing extensions or some other high level core code, you probably won't need to create things like unit or integration tests.
However, it is good practice to have at least some sort of functional tests and to run them during deployment. These can be as simple as opening a route and checking the return code to be a 200.
public function testBasicRoute()
$crawler = $client->request('GET', '/');
$this->assertStatusCode(200, $client);
}
2. Manual testing
If you don't want to write automated tests, then let your customer/stakeholder/whoever test the system for you. Actually, that is exactly what the stage system is for. Send them a link, to the stage server, where they can see and verify the changes you made and have them take a look at it.
I always recommend not letting your colleagues or yourself do it. You might be to close to the code and the problem and you might not even seen problems regular users will have. Always let someone who is more of a user than a developer test the system.
Deployment
To finally make sure that nothing breaks after changing stuff, you should set up a proper deployment. For that you can use anything you like, starting with GitLab pipelines, Deployer, or even a bash script.
The point here is: Automate it! Make sure you don't forget vital steps necassary and also make sure that if something breaks during deployment the deployment stops and doesn't take down your website.
As you can see, with my deployments it doesn't even need to be very complicated. After the testing was done on the stage and the dev branch, I merge dev directly into master and that triggers an automated deploying of the latest changes.
Backups
Aaaaand last but not least: You need backups! Since most CMS are not that complicated, you most likely just need to backup your database and your file system. Your provider should have some sort of backup options. If not: get a different ISP.
However, even if your provider does have something like this, you should still do your own - just in case. It's not that hard, download all your files and make a copy of the database. You can even use that for local development then.
No Backup - No Pity!
Conclusion
This post was just a very shallow overview over a few things you should do to make your TYPO3 Development/Maintenance more safe and secure. A real deep dive into the details would be way too long for this little blog. If you or your agency is struggling with this process, I can help out with that and create you a perfectly designed DevOps solution, that includes everything from your local environment with docker over your server to your live website for you. Just hit me up and lets talk.