Which webserver do you use in production?
0 voters
And which webserver do you use in development? Do you prefer the same? Or not? Or you don’t care? Why?
0 voters
I’m especially interested in the feedback of developers that use laravel valet / valet+ / homestead / … who use nginx in development, but apache in production.
Great, first reply and already a change in devserver vs productionserver 
Care to share your opinion about that @jimbobrjames? How do you cope with the difference in config files (htaccess - redirects - caching setup - …)? Also with e.g. setup of imagemagick? Or other finicky, tricky server-specific stuff which can go bonkers? I tend to replicate my production server environment as much as I can on my dev environment so I can test most before deploying.
Laravel Valet user here. I usually have an Apache test server running remotely as well during development where clients can follow development.
to be honest, it rarely goes bonkers. I use Valet locally which has built in support for Kirby. It ignores the .htaccess, since it has a built in nginx config for Kirby. It also uses stuff on your system so i just install things like MySQL, ImageMagick and GD via homebrew and off you go.
On the server itself, i make a dev.domainname.com to use as staging and do atleast one deploy there before launch to make sure it flys, since this is on the same environment as live.
The only thing i match up on the server is the version of PHP I used locally.
I use XAMPP as my development environment (e.g. XAMPP 7.2.15 [Apache/2.4.38 + PHP/7.2.15] or XAMPP 7.3.12 [Apache/2.4.41 + PHP/7.3.12]) on an external USB hard disk locally connected to a Windows computer, e.g. a Win10 64-bit laptop.
On the web server of the production environment Apache is running, but here under Linux of an external hoster.
In my experience, switching the web server software between these two environments should be avoided at all times.
[Added:]
I can think of NO reason why I should use nginx in development, but apache without nginx in production.
Why should I voluntarily expose myself or my development to such a trap?
Hint:
You can download XAMPP for all major development environments free of charge at the link “https://www.apachefriends.org/index.html”.
At least under Windows there is an additional “portable” version of XAMPP available under the link “https://sourceforge.net/projects/xampp/files/XAMPP%20Windows/”, which can be installed without admin rights and used without admin rights.
For development I’ve started experimenting with Caddy 2, which is now in beta and soon to be released. Very very simple to set up with PHP and also very flexible to configure.
Update: Caddy 2 beta 12 (the next to be released) will fully support Kirby 3 with the following simple Caddyfile:
localhost:80 {
root * /path/to/your/kirby/installation
tls off
encode gzip
file_server
php_fastcgi localhost:9000
}
(assuming you have PHP-FPM running on port 9000, which is the default port)
I tried Caddy once after @gillesvauvarin talked about it but wasn’t successful (although I can’t remember what the issue was). Maybe I’ll try again once the new version is released.
Yes. This Caddy 2 looks interesting. Valet works well for my needs, too.
Caddy 1 isn’t as polished, but Caddy 2 is really amazing. It’s a bit difficult to wrap the head around it at the moment (docs are missing in some places and not all features are supported in the simplified Caddyfile syntax, only in raw JSON), but it’s going to be great. I will already use it as my new dev setup in a few days.
The developer of Caddy is really nice as well and has implemented the necessary fixes to get Kirby 3 working after only a few hours this morning. 
We use MAMP for local development. Our staging and production servers all use BOTH Nginx (setup as proxy) and Apache (behind Nginx). This double setup seems to also be the standard in most cheap shared hosting services we’ve come across. This means you get some of the speed advantages of Nginx, while still keeping all the compatibility advantages of Apache. - ie., .htaccess files work, and the usual Apache modules are already installed and working as expected.