Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can.

However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:)

For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated.

Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to

1. Generate composer autoload cache files 2. Fetch, download and install any updated composer packages (i.e. third party libraries)

Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that.

How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines.

And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems.

Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)

> They really aren't similar at all. Forge manages sub-domains, Nginx, Cron jobs, SSL certificates, queue daemons, recipes, etc. Envoyer does none of those things. Envoyer is solely focused on deploying PHP applications to multiple servers with zero downtime.