Symfony 6 Certification New exam with updated questions 100% online Show your expertise

The end of Silex

What about Silex in a Symfony 4 world? During the last few months, and as an exercise when working on Flex, I have migrated several applications from Silex to Symfony 4. And the conclusion is that Symfony 4 feels like using Silex.

Using Symfony 4 and Flex feels as lightweight as using Silex. You have full control about what features you want to enable or disable. The directory structure of both kinds of applications is similar with limited depth. And Symfony 4 is superior when it comes to the ecosystem. Whenever you need something, odds are that a bundle already exists for it. And for major ones, a recipe makes integration a breeze. And that's a great selling point of Symfony 4: it scales from very simple applications that just need a router and classes for HTTP messages to a monolith including bells and whistles.

Moving away from Silex is also made simpler as Symfony 4 almost auto-configure all your services. So, migration from Pimple is mostly about removing all the code without any replacements in the Symfony config.

For all these reasons, I would say that Silex is not needed anymore. So, we've decided to not support Symfony 4 in Silex, or at least not add the new features added in 3.4. The current stable version of Silex is still maintained for bugs and security issues. But its end of life is set to June 2018.

Having a unified community around Symfony 4 and Flex is great news and one implicit goals of all the work we have done during the last few years around DX experience.

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.


Ah great news!
That makes thanks to me :)
Sad but true. RIP Silex, I would love you forever!
Really great news, Silex still a great project but with the new tools offered by Symfony 4, using Silex is kind of complicated and probably not desired if we want to build a professional and future-proof application.
I've great experience with silex and had developed many applications using it. I love the flexibility and lightness of the framework. Surely miss it.

As Symfony 4 and Flex feels as lightweight, It's time to move with it. Good news.
Thank you for all your contributions.
Could you share with us some tips about how to migrate from Silex to Sf 4 ?
For those looking for a guide explaining how to upgrade from Silex to Symfony 4, it's not ready yet but we're working on it. See
I hope that silex isn't removed from universe, just declare its death and leave it there, as I still maintain lot of silex based project.
The Silex repositories and the website won't be "removed" any time soon.
I have been playing around with Symfony 4 as I saw this coming, Symfony 4 does seem like a nice upgrade and I'll be looking to port my silex apps over to it soon.
Sad day but I really get the point. If it wasn't for Silex, maybe I wouldn't be such a Symfony fan. It really made it easier to overcome the deep learning curve of mastering Symfony, that was 6 years ago, with Flex, we get all the flexibility, it doesn't matter how big the project is, so it makes sense to end Silex.
I was able to use silex with dbal without downloading the doctrine/orm. Will I have the such opportunity in smf4?
Shmakov Vadim: Sure, this has been possible with Symfony 2 already and probably won't change as long as Doctrine is supported.
@Shmakov DoctrineBundle does not have a strict requirement to the doctrine/orm, precisely to allow using only the DBAL part.
This is unbelievable. You guys have no clue what professional software development is like. We've base so many projects on Silex and the customer spent so much money on them. And now i have to tell them they need to spend tenthousands of dollars just because we need to migrate to a new PHP framework? What are you thinking?
@gregzuergre here you can find useful resources and examples about how to migrate from Silex to Symfony 4:

Also, I must ask you to show more respect in your comments. You can say anything you want, but please don't offend others when saying it.
This is totally irresponsible. Why are you only supporting it for 6 months? You should at least offer bugfixes for 3 years. I don't think any enterprise developers will trust you guys any more.
@gregzuergre I think you don't understand how Open-Source works. I've been giving my time to Open-Source for the last 14 years. Benevolent. I've never discontinued a project. Not a single one. Oh, and in 2017, I'm again the developer who contributed the most on Github, from ALL developers on the platform. So, I think I've done my part of the job.

That being said, I've asked many times for help on Silex. Nobody step up. You are using Silex as part of your business. That's great news. But where were you when we needed help? What have you done to make Silex a successful Open-Source project? *You* are irresponsible. You don't understand how Open-Source works.

And we don't abandon the project. We give a way to upgrade to Symfony 4. And we did that because we think that this is the best way forward for people using Silex. Silex is based on Symfony. Call it Silex 3 is you want. The name is not so important.

Anyway, if Silex is a critical piece of software for many businesses like yours, if you think there is value in Silex, there is still the possibility for you and others to take over the project, keep it live. I'm not even asking for a hard fork. I'm willing to transition the project to a new team. I would even be more than happy to help a new team. That would be wonderful. Are you in?
@fabpot, could we highlight on the Silex official page about this decision. I do not see any announcement or disclaimer on
This announce is quite sudden, with few clear public signs before to anticipe short Silex's end of life, despite some recent indices like the release of a lighter Symfony (that could be an alternative at this time), less activity on Silex repository, less articles on the web about it.

I think the numerous users of Silex would have appreciate :
- a clearer and more anticipated planning on end of maintainement; 5.5 months is short indeed for organisations who adopted, learned this tool and developed solutions, products on it; they have not necessarly ressources (in time and financial) to do that in this time, among probable other existing tasks and priorities
- despite a migration to S4 looks simple, it's still not very clear; I have seen this issue created in GitHub and a couple of articles on the web. Proposing a visible documentation about it (on and notably) would probably not let users in confusion. Also, I have seen some questioning on the web concerning migration to S4.

It's annoying that Silex homepage is still unchanged, with the misleading appearance of a still valid solution on which I could start a new project.

@Fabien It's possible I doesn't understand Open Source too, but you answer surprises me a bit. As a *user* of a framework and following his evolution (not from his start however), but not able to participate actively in the development, I discover here with project "internal" things. Was it well-known that Silex needed help ? For a long time ? Should we be more informed and implicated ?
I think gregzuergre doesn't question you engagement but in this case the responsability of managing the end a solution after it was launching and distributed.

Personnaly, I learned Silex and implemented it in 2 projects in 2017 and you can imagine my astonishment when learning early 2018 Silex's short end.

Anyways, I agree with most of your decisions in this post on Silex's end of life and future with Symfony 4, but the communication, preparation and migration's documentation could be a bit more neat for the users of this framework established for years.

Maybe your last answer could complete the post, as it contains notable precisions.
There seems to be some movement on taking over Silex maintenance. If you are interested check out this issue:
So far I've notice a huge benefit in moving to symfony, one being that Phpstorm is more adaptive to it compared to Silex in terms of finding everything.

also I like the fact I'm now have more resources at my disposal and don't have to try to renege a symfony tutorial to fit silex.

I understand the anger of those who are frustrated in this, but I do remember Fabien asking for help to keep Silex moving, so the community can take blame in Silex being pushed to the pasture to rot.

I do see some devs want to keep it alive and I honestly hope they do as Silex is a great framework if you just need some bolts and screws to make a platform without needing a whole toolset that's not needed.

I've move onto to Symfony 4 and not looking back :)
Every product have an end of life and of support. Your car, your sofa, your fridge, your phone, your computer. You can't blame a company to stop manufacturing a product or stop supporting it. It is part of the game. With Open Source Software, this is quite the same but with better issues: on an OSS ends, everyone who wants to continues can. Instead of blaming the team under Silex, what about thanks them for the hours spent gracefully on that project? Plus Silex seems to be the favourite framework of your teams, what about asking to be maintainer?
The Silex project was my choice when I needed to switch from TinyMVC to Silex because a project of mine became bigger and was in need to get easier to maintain. Now, that Silex ends, I get the opportunity to collect experience in another framework. It won't be Symfony, because I already did too much with it in the past, and the PHP community isn't all about Symfony, even though some components are present in many other OS libraries and frameworks.

I want to thank to all who put work into Silex, including Fabien of course. It was fun to work with Silex and even Symfony itself has learned a thing or two from it.

I wonder what would happen, when on April 1st a message is going to be released, that Symfony will end. :-)

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.