Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Normally you’d want to use either root or alias on the location block when you’re referencing where files should be pulled from if they are not located in the web root.
So in the above configuration, you’re specifying that this is your web root:
/home/forge/www.domain.com/public
That means that content will be pulled from:
/home/forge/www.domain.com/public/content
site will be pulled from:
/home/forge/www.domain.com/public/site
kirby will be pulled from:
/home/forge/www.domain.com/public/kirby
subdir will be pulled from:
/home/forge/www.domain.com/public/subdir
and panel will be pulled from:
/home/forge/www.domain.com/public/panel
Is that the intended location for each directory? We should start there as much of your rewrites are targeting those directories and unless you need specific functionality, the blocks with rewrites would be much better off written as:
location /content {
alias /path/to/content;
}
location /site {
alias /path/to/site;
}
location /kirby {
alias /path/to/kirby;
}
I would also remove these blocks:
if (!-e $request_filename){
rewrite ^/panel/(.*) /panel/index.php break;
}
if (!-e $request_filename) {
rewrite ^/(.*)$ /index.php last;
break;
}
I tried to request a Node.js App beside the main kirby installation.
It works if I remove:
if (!-e $request_filename) {
rewrite ^/(.*)$ /index.php last;
break;
}
and I see nothing which doesn’t work in kirby. What is the reason for this rule?
Looks like Bastian is also not using this rule: https://gist.github.com/bastianallgeier/c2e1f1e519f5f2943ec4
Thanks @jtittle! I tried the alias directive for the /subdir location block, but it didn’t change the behavior.
Those rules (content, site, kirby, panel, $request_filename) are for blocking Kirby CMS directories. It’s basically a translation of the .htaccess rules here.
The /subdir directory is the one containing the WordPress installation. The links where a file can be found (domain.com/subdir => /subdir/index.php, domain.com/subdir/wp-admin/ => /subdir/wp-admin/index.php, domain.com/subdir/wp-admin/post.php?post=[postnum]&action=edit, etc) work, but when going to a permalink (domain.com/page-title) it returns a 404. If one goes to the non-permalinked url (domain.com?p=[postnum]) it 301 redirects to the correct permalink, but that url then 404s.
Here’s a little more info about the VM (where the simple try_files directive is working) and the droplet:
VM
nginx 1.11.1
Ubuntu 16.04
PHP 7.0.16
DO droplet
nginx 1.11.9
Ubuntu 16.04.2
PHP 7.1.2
They’re not huge differences, so I’m not sure why it’d be working fine in the VM but not on DO.