You can make use of the STAGING environment variable to verify your configuration is correct without counting against LetsEncrypt’s rate limiting policies. You’ll need to input your Cloudflare email and Global API key. ini file under /name-of-swag-volume/dns-conf/, which in my case is cloudflare.ini. Make sure to make the appropriate changes in the respective. PUID=1000 - PGID=1000 - TZ=$TZ - URL= - SUBDOMAINS=wildcard - VALIDATION=dns - DNSPLUGIN=cloudflare # - STAGING=true volumes: Image: ghcr.io/linuxserver/swag container_name: swag networks: So once again, this is what we’re trying to accomplish: This way, there’s no need to create individual CNAME records at my DNS provider, and my services will be available at. At its core, SWAG is simply an Nginx reverse proxy that is paired with LetsEncrypt and Fail2Ban, packaged into a neat little Docker container. I set everything up using SWAG Reverse Proxy with wildcard certs and DNS validation. I’d like to have that nice SSL “locked” icon and a valid domain to go to. I could just create a DNS record for it so I can use a domain name, but then I have to see that horrid “Not secure” message at the top of my browser. I could just access it from the IP address and port, but that gets kind of annoying after a while. I also want on the Linode instance, because it is also public facing.įor example, I host Radarr at home. But I still want the blog to be located at, because it’s about my homelab, but also on the Linode instance ( Server B), since it’s public facing. I want to continue using at home ( Server A), because it’s for my homelab services. I decided to go with first-initial-last-name, so. While doing this, I realize I should probably have a professional-ish landing page for myself it can house my resume and experience, an ‘About Me’ page, and link to my blog/Github/LinkedIn, etc. To do that, I spun up a cloud instance on Linode. This is awesome, as it means I don’t have to spin up a separate Nginx container just to serve the generated site, I can simply point it to my reverse proxy and it’ll be available at my chosen subdomain, .Īfter learning how to operate Hugo from a container and pointing it at my reverse proxy, I decided I wanted to migrate the hosting infrastructure to the cloud it works 100% fine locally, but I’m making an effort to start moving public facing things outside my LAN when practical/possible. It can then convert that project into an HTML website (based on a theme) and serve it using a built-in live-updating web server. ![]() Hugo works by creating a project directory using Hugo commands, and then creating your posts/content in the form of markdown files. So now I had my blogging platform chosen. There were a multitude of options available: Hugo, Gatsby, Jekyll, Next.js, etc. There is no database to interact with, and since it’s a static page there’s an added security benefit, as there isn’t a plethora of plugins to install and maintain.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |