Host a Wordpress Site

Hi !
I want to host a website with my NAS and create it with the Wordpress application. Except that I don’t know how to make my site accessible to everyone? I looked at lots of tutorials and searched forums but couldn’t find anything…

Salut !
Je veux héberger un site web avec mon NAS et le créer avec l’application Wordpress. Sauf que je ne sais pas comment faire pour que mon site soit accessible par tout le monde ? J’ai regarder plein de tutos et chercher sur des forums mais je n’ai rien trouvé…

Th easiest way IMO would be a virtual machine with your favourite Linux distribution and webserver. And then just install Wordpress as described in their manual.

Is everybody the internet or just your internal network?

1 Like

I already have Wordpress with TrueNas, in fact I want the site to have a domain name and to be able to access it from any location.

You’ll need to understand how to setup a NAT to port forward your application. Every firewall is different so giving an answer to this might be difficult.

1 Like
  1. If you want to use a regular domain name, then you will need your Internet provider to issue you with a fixed IP address. Alternatively register a host name with a free Dynamic DNS service and install a Dynamic DNS app - I use ddns-updater from the TrueNAS Charts.

  2. If you haven’t given your NAS server a fixed IP address on your LAN, then you need to do that too.

  3. On your Internet firewall forward port 80 to whatever IP address and port your Wordpress App is published on.

1 Like

Somewhere in there needs to be something to terminate TLS, as HTTPS shouldn’t be considered optional on the public Internet–if the Wordpress app doesn’t do it itself (and if it does, you’d need to forward both 80 and 443 to it), that means a TLS-terminating reverse proxy. Options for that include, in no particular order:

  • Nginx Proxy Manager (NPM) app from TrueNAS
  • NPM app from TrueCharts
  • Traefik from TrueCharts
  • Something suitable on your router (Caddy on my OPNsense router works well in this regard; HAProxy on pfSense or OPNsense would be other possibilities)
  • Anything you want (NPM, Apache, Caddy, HAProxy, Traefik, plain Nginx, etc.) in a sandbox or VM on your NAS

And then you’d forward 80/443 to that reverse proxy.

1 Like

@dan definitely has a point - any web site which has a login access definitely needs to have encryption (and to have secure cookies set too) - and wordpress (and all CMS’) have admin login even if the public don’t need to use it.

Also, you MUST keep wordpress up to date - and possibly provide additional safeguards as there have been many exploits hacked over the years. (I used to be a Wordpress admin.)

1 Like

I’d go further and say any web site exposed to the public[1] should have HTTPS. Really, there’s no reason not to. And even if you’re just serving plain static text, your visitors should be able to view it privately.

If you’re dealing with anything that’s at all sensitive–and login credentials definitely qualify–then it’s mandatory IMO.


  1. I try to have my LAN-only resources HTTPS too, but for some of them that isn’t practical–though that list is shrinking ↩︎

1 Like

Anything that can be publicly accessed is by definition not private - though I do accept that you might not want people knowing that e.g. you are accessing publicly accessible porn, so the knowledge that you as an individual are accessing might need to be kept private.

But a web site on e.g. the classification of garden snails does not IMO need to be encrypted.

1 Like

The information itself may be public[1]; the fact that I am viewing it should not be. Which is what I said: “your visitors should be able to view it privately.”

A few responses to this:

  • If encryption is the norm, then it isn’t a marker of something valuable, or really of anything
    • If you only encrypt information that “needs it,” then an attacker knows that encryption = valuable information.
  • If encryption is the norm, an attacker[2] has a much harder job to determine my browsing habits
    • This is why, when you’re disposing of classified information by shredding it, there’s a minimum number of pages that have to be shredded before you can throw it out–the more stuff you’ve shredded, the harder it is for an attacker to put it together.
  • Maybe there are reasons I don’t want other people knowing of my interest in garden snails
  • And while that particular example might be a little silly (I certainly can’t think of any such reason), where’s the line? Can you know as a site operator that all of your visitors will be cool with it being public knowledge that they visited your site?
    • Your blog on the history of the Roman Empire, for example, could be seen as subversive by another government, particularly if you’re drawing parallels between its decline and the situation in that nation. A reader in that country might not want it known that they’re doing so.
    • I dabble in high-power rocketry. Sites discussing the formulation of rocket fuel, which some in this hobby do, could similarly be disfavored in some environments.
  • HTTPS doesn’t only provide privacy, it also provides data integrity, preventing a MitM from altering the data in transit. This isn’t just a hypothetical concern; ISPs have been known to inject ads into HTTP web pages.
  • And while DV certs (the most popular by a wide margin, largely thanks to Let’s Encrypt) don’t do much in this regard, there’s still some validation that you’re communicating with the site you think you are.

HTTPS is the norm for a website these days, to the extent that all the major browsers are marking HTTP-only sites as “not secure.” It costs nothing[3], and the software tools to implement and automate it are quite mature by now.


  1. or it may not; just because the web site is public doesn’t mean that all its content is ↩︎

  2. …and your web traffic passes through a lot of parties between the server and your browser–how much do you trust them? Do you even know who they are? ↩︎

  3. Sure, in an extremely high-traffic environment, the extra compute load for encryption might be noticeable–but that’s not what we’re talking about here ↩︎

2 Likes

Thank you guys for your answers, what you said is interesting but I’m just starting out so your explanations didn’t help me any more… If someone can tell me clearly and easily what I need to do so that my site is accessible to everyone with a DNS, that would be great! THANKS.

@Metre_Bambi I already did.

@dan I am persuaded.

I installed ddns-updater, because my box does not provide a fixed IP address, however my NAS has a fixed IP address, what should I do because I didn’t quite understand. Thanks in advance !


I hate to say this, but if you’re asking these questions, you really don’t have any business putting a website on the public Internet–these are basic networking issues that you’re going to need to learn, and this really isn’t the place to teach them.

But with that said, you need to configure ddns-updater to monitor your public IP address, and to update your DNS records when it changes. You’re then going to need to configure your router to forward ports 80 and 443 to your reverse proxy (likely Traefik, if you’re using TrueCharts anyway[1]), and configure that reverse proxy to handle traffic for your wordpress site (which would be handled through the Ingress options for your Wordpress app).

If that last paragraph was gibberish to you, you have some reading to do until it makes sense. In the alternative, you may be better off finding a hosting provider who will host your Wordpress site for you.


  1. but this will open up all apps for which you’ve configured Ingress to the public Internet ↩︎

1 Like

Hi All, I could use some help with WordPress app install on TrueNAS Scale.

Doing the install using the package generated folders works without a problem. But I wanted to separate out the app files from the website files… app can always be upgraded or reinstalled but I want my website files in a place for backup more regularly that config files.

There are 4 sets of files (options from the app install):

  1. Wordpress data storage - I think these are the app and it’s config
  2. MariaDB - this is kind of a mix of app and content (so I will consider this website files)
  3. MariaDB backup - guess this is a copy of the above so again will consider this website files
  4. Additional Storage - not sure if this is needed? though this might be where I could download new plugins or themes etc. but don’t actually know

Questions:

  • How should this be organized? Dataset for apps-configs (with folders for each app or child dataset for each app?) Then another Dataset for Databases (with folder for flavor of DB and app using it? or child datasets?)
  • What permissions should be on each of these sets of files/data for Wordpress? where can I read up on this? are these the group I should be concerned with? apps, www-data, etc.
  • If I’m using child datasets… does the parent data set need the widest access for all apps? guessing yes…

Got some help.

  • Wordpress Data needs the group “www-data” to have modify permissions
  • MariaDB and backup need the group “apps” and “netdata” to have modify permission