We're going to play with FrankenPHP and see if it might actually change how we deploy PHP applications. We're going to see what it looks like to use FrankenPHP in just a second. But let's see what FrankenPHP is, right? A modern PHP app server written in Go. FrankenPHP is mainly concerned about how it serves PHP applications. So it's going to use Go. The Go thing it's using is a web server. That web server is Caddy. Caddy is actually a pretty popular web server written in Go. How does FrankenPHP actually use Go? That's a good question. Caddy, it turns out, has a modular system. And this is a Caddy module. So what happens is Caddy receives a web request from the internet and runs this FrankenPHP module. And the FrankenPHP module does all sorts of crazy stuff like a C-based thread pool and all this good stuff. It spins up PHP processes with a lot of concurrency, right? So it can actually handle a bunch of requests at the same time. It compiles

down with the thread-safe version of PHP. It does all sorts of fancy stuff for us. And all we need to care about is that it's going to run our application, which is great. So it native support for HTTP 1, 2, and 3. It creates SSL certificates for us automatically. These are actually all features of Caddy. It's not specific to Franken. So that's pretty neat. There's worker mode. Worker mode is just like Laravel Octane, right? So Laravel Octane isn't yet supported, but will be soon. But that's all worker mode is. In other words, it loads your framework once into memory and then just keeps sending requests to that same instance of your application. It does not spin up a new instance of your application for every new web request, unlike PHP FPM or actually Franken does normally without worker mode. Okay, so let's see what it actually looks like to use this. I have a PHP application here, right? So if we do PHP artisan serve, I can go ahead and open this in a

web browser here. And if we load it in our web browser here, we'll see at the bottom the SAPI. SAPI is the server application programming interface. That is the thing that sits between your web server and your application, right? So PHP FPM, Apache's mod PHP. Sorry. What else? CLI server, right? When we just run PHP artist and serve and now Franken PHP, right? So if I go ahead and run Franken PHP to load our same website here, the SAPI is Franken PHP, right? The person who created Franken created their own SAPI, this thing that sits between your PHP application code and the web server, right? What is actually the benefit of this? To me, the biggest benefit of Franken PHP is the ability to bundle up your code into one thing and ship that anywhere, sort of like Golang. But I didn't show you actually how it looks like to run this thing. So the easiest way to run this thing is actually in a docker container. It actually likes to be in docker the best. You don't

need Docker to run this, but you will have the easiest time running it in a Docker container or using a Docker container to build a binary and running that binary on your Linux server somewhere, not in a container. You can do all that stuff outside of containers too. It's just a little easier because it's wrapped up in a nice package for us this way. So we're going to do Docker run, remove this when I'm done with this container, share my application, right? This is a layerable app in the frankenized directory here. So put that into the container in the right place. Use port 443. I'm not even going to bother with port 80 because this creates an SSL certificate for you automatically. Even if you're at localhost, use the container image that Franken PHP created. And I don't want this command. I just want no command. And that's going to spin up a web server for us. So this is a bunch of structured logging output. It's

the result of Caddy doing its thing, and also the Franken PHP module that runs inside of Caddy. I can go ahead to localhost with HTTPS, load this page up, and the connection is not private because it created a self-signed SSL certificate. So we can still visit this website. Yes, I want to visit the website, and it's loaded. Okay. So down here, we see this happy Franken PHP again, and that's what it looks like to run a layerable application in Franken PHP. It's just this one Docker command, which is neat. That's fine. Let's actually see what it looks like to package up our layerable application into one binary that we can ship anywhere, even if that anywhere does not have PHP or anything that installed in it. This is what I think is really game-changing about Franken PHP. We can package up our application into one neat little thing and just ship it off to any server, which makes deployments a lot easier and simpler. Okay, so I mentioned we need to use

Docker for this, and we don't need to, but I'm going to because it's the easiest way to do it. So I'm going to create this file called static build a Docker file. And in this Docker file, I'm going to steal directly from Franken PHP stocks, a thing to put in here that's going to build our application into one little binary. Then we copy that binary out of the resulting container or image that we create the Docker image. And then we can just run that anywhere we want, like on a Linux server or something. Okay. And this is the content of that Docker file. It's the static builder Docker image that Franken PHP provides. It's from AMD 64 servers right now, not ARM 64. So this might not work on your Mac or your M1, M2, M3 Macs. I'm not actually sure you should give it a try. And then we can just run the stuff to create our application and bundle it

into one little binary, right? That's the build static.sh bash script that runs in the Franken PHP repository. And we can see we can set some stuff like PHP extensions. I only have a few here, but if I remove this, it's actually going to build in like almost all the PHP extensions you might think of. In fact, if we head to their repository, find the build static bash script. Static, where are you? Build static.sh. We can see PHP extensions. If it's not defined, if it's empty, that's what dash Z means, then it's going to build in these extensions by default. If we're on our Mac OS, we build some of these. Otherwise, we build some of these. And I think the only difference is it just doesn't have Postgre by default on Mac for some reason. I don't know. I could read this GitHub issue. I'm not going to. All right. So let's head back over here. And I

think I can just go ahead and run this. Now I'm running this relative to my Laravel application, right? So it's going to copy in my Laravel application code files here. And this is just for local dev. But in reality, you'd want like your production.env file and all that good stuff. So let's see. Let's do docker run. And how do I run this thing? So I'm going to say this. I'm going to set a variable. The variable is going to name this image static app. And then I'm going to copy and paste from over here. My notes will do docker build dash T app name, like static app. And using the static build Docker file in my current directory. And this is just going to go ahead and build our application into the resulting image, this Docker image here. Okay. And that is finished. This took like, I think about 30 seconds after Docker finally pulled down the Docker image. So it's actually a pretty quick process. Now there is a zany command

we need to copy this file out of the resulting Docker image. What this thing is doing is doing the Docker copy command, which can help you copy a file from a running container onto your host computer, right? So we're going to get this onto our Mac OS computer out of that Docker image. So it's going to create, which is just going to create a container, not just from the Docker image is going to create a container. It's not going to run it, but just create it. It's going to name it static app temp. And it's going to create our app image here. The image we just created is named app image. And then from that container, it's going to copy this file, Franken PHP, Linux 64, 64, whatever, I can't talk. It's going to name it my app. And it's going to place that onto my Mac OS host here. And then it's going to remove the thing we just created.

because it doesn't need it anymore. Okay, let's go ahead and do this. And now we have a directory or file here named my app. And we can run that now. I can't actually run that directly like this because I'm on a Mac, and this was built for Linux. So what I can do is actually fake it, pretend to run a Linux computer. And I'll just do that through Docker again because we have it here. So I'm going to do remove dash v, no, I'm not going to share anything. I'm going to do port 443 in this container, port 443, Ubuntu 2204. Okay, so I'm spinning up an instance of Ubuntu 2204. This means it will not have PHP installed on it, it'll be nothing but a base virtual machine, which in this case is actually a Docker image of Ubuntu. And it has nothing installed on it at all, right? It's just Ubuntu. And actually, you know what, I'm going to share a thing, I'm going to

share in my current directory, the file my app into where we want to put this. I'm gonna put slash serve my app inside of this Docker container. And then I'm going to run, I'll just run bash here. Oh, I totally did this wrong, dash it, I need that dash it flag. So we're actually attached to the Docker image, and we can do stuff in it. Okay, so we're in the serve directory. PHP is not installed, there's no web server, nothing installed on this Ubuntu container at all. So let's go ahead and run my app. We'll do PHP server, and I'm going to add domain localhost here, because that tells caddy to create an SSL certificate for localhost automatically. And that will run it here. Okay, so it's done the TLS stuff because we use that flag to give it a hostname. And since that's running in port 443, we should be able to load that up here.

let's do HTTPS localhost. We get our usual connection is not private. And it works. And we're in the sappy Franken PHP. So what have we done here? I have created this little binary, my app. I put our application into it. It has caddy in it, right, our web server. So it's a self-contained binary that we can ship to any Linux server or virtual machine Docker container in this case and run it, right. So it's actually just like shipping a Golang program where you compile your Golang app and it becomes a self-contained binary you can ship anywhere at all. And we get the same benefit with Franken PHP, right. We can build our Laravel application into this little thing and just ship it off to wherever we want to run it. It can be in a container. It can be in a Linux server somewhere. You can build it from macOS if you want to, but you know, typically, in production, you'll probably be running a Linux server, right? And let's see.

how big is this thing? It's 168 megabytes, which is really not too bad. It includes a Golang program. Includes your Laravel app with your vendor directory. You don't have any node modules, in this case, that'll probably blow it up even bigger. But hopefully, you don't even need those for production because those are only used for building your static assets, right? So what we can do here is build up a process where on push to production to deploy our code, we can get our non-dev dependencies from composer. We build our static assets, and then we get our production.env file into one location, run this build process, so we get our application built. And then we can ship the results, this my app binary, or you can name it whatever you want, we can ship that into production by just kind of like swapping out the binary, which binary is running. So we don't even need to, you know, do all this stuff on our server, like Laravel forge likes to do a quick.

what is it called a quick deploy, where it does a composer, you know, pull and all that stuff, and it's not really zero downtime at all. Or you might use envoyer, which does the same thing, but runs it and does like the symlink dance to create a zero downtime deployment, but it's still running all this stuff on your production server here, we can actually just ship a binary and just put that wherever we want. And we don't need any stuff installed on the server at all. Right? No PHP, no web server, all that stuff, we just have it all contained into this one file. I think that's pretty revolutionary for PHP, right? Because that's something you only get in other languages like Golang. And that's just sounds so awesome to me such a better deployment story. Now, are there downsides to this? I don't know. You know, it's not nginx. nginx is written in C, it's super

performant. Caddy is not as fast, but can still handle a lot of traffic. Golang is still performant, right? People use Golang-based web servers all the time in production, like traffic and all that stuff where they're writing requests and making microservices and all that stuff is highly used in production. So I wouldn't be scared of it from that point of view. But you know, it is technically a little less performant. It's just like, it doesn't matter for most of our applications. Caddy does a lot of cool stuff. The logging is better. Let's just check out Frankensite, there's so much stuff, right? It gives us structured logging, Prometheus metrics, which are really nice for monitoring your site, graceful reloads, HTTP three, and gzip, and all that stuff is supported. Worker mode when Laravel Octane support finally hits, worker mode is supported. So that's great. And it's easy, you know, it's what kind of just works. Alright, so I think this is

really cool. I'm going to try using this in production for myself. But if you have any thoughts, ideas, comments, questions, if you think I did something stupid, if you think I missed some important points, please let me know in the comments, jump in there. Let me know what you think.

The secret behind FrankenPHP: Will it revolutionize PHP?

Scripts