The guide exposes the back-end webserver to the public, by accident.
Instead of:
ports:
- "2368:2368"
expose:
- "2368"
The author probably just needs:
ports:
- 127.0.0.1:2368:2368
That way "localhost:2368" will be routed to 2368 inside the container, such that caddy can access it, but not accessible externally, as it is right now:
$ curl -v https://sphuff.com:2368
Though of course the ideal solution would be to run caddy as another container, and link them together.
Little more complex than that. They issue a command that ends up downloading a bunch of shell scripts and goes from there. Does a lot of other nasty things too like trying to steal any ssh key on the machine to presumably use those machines to mine.
Luckily running inside of docker prevents a lot of that by default.
It is very noticeable though when you log into your dev server and the cpu is pegged at 100%.
Ding ding ding, we have a winner! This is exactly the process I landed on this week when I decided to start a blog. There's literally nothing cheaper or more convenient (or resume-appropriate, since I already share my github) than github pages. Generating a static site is almost trivial (I landed on using Hugo, but a bunch of solutions are just as easy).
To take the laziness a step further I use emacs and org-mode and publish with ox-hugo (https://ox-hugo.scripter.co/). Set up an org-capture for the blog template, and I'm only a few keystrokes away from creating and publishing a new post at any time.
Fair warning: keep up to date with your Hugo version locally, or use a set version in GitHub Pages.
I'm using Gitlab Pages with latest version of Hugo pulled by default. I don't post as much as I did, and have twice had to spend over an hour getting a theme updated for the latest version of Hugo since I didn't update my version and there's been breaking changes.
Outside of that, Hugo is fantastic. Good luck with your blog!
I have really struggled with Hugo’s organizational structure, and for some reason I always end up with pages that are supposed to be lists of posts being completely blank for no reason. No debug messages or anything. I would have to just clone the repo and start stepping through which I do not care to do.
Hugo’s insistence that you have to have a theme is infuriating. I don’t want a theme, I want html and tiny bit of CSS
I’ve tried three times to switch over and it all ends in frustration. It amazes me that I just can’t wrap my mind around it, or just can’t let go and have it force me into it’s opinions about how to structure my site. It's completely possible that I'm just an idiot.
Glad that I wasn't the only one to have alarm bells go off in my head when I read that first step.
There are plenty of other rational options, most people are saying github pages, but I'd like to put forth the NeoCities + Hugo combo as an alternative. It's a bit more complicated than I'd like but it's absurdly easy to modify and make content for once it's set up.
I host two small websites on my $5 DO droplet, and I use Docker to keep everything its own space. The entire deployment process if I wanted to start with a brand new VPS is about 15 minutes. I think Docker makes my deployments a breeze, and it hasn't forced me to cough up any extra money.
Yeah, creating a Docker container and setting up Caddy seems like a lot of work.
Netlify, Firebase Hosting, GitHub pages, etc, all make it super easy to host a static blog for free, require zero maintenance, and are all backed by global CDNs.
My blog setup uses Netlify to automatically build and deploy on a git push using the built in Hugo support.
Now of course, there is the argument of what "self-hosting" is. Does it just mean you own your domain name and content? Or does it mean you are actually running the server? If its the latter, then sure this is a valid solution, but if all you care about is owning your domain and content I'd use one of the static hosting providers.
I heard Troy Hunt say about why he uses a blog service instead of hosting it himself, (roughly) "Do I want mess around with server configuration or do I want to write?"
Not disagreeing, but the post is titled "Self-Hosting a Blog" which I would assume means that the blog author has already made the decision not to use GitHub or Netlify (for some reason, don't know why).
The truly cheap would go with one of them and avoid the $2.50 monthly fee for a server.
I rather just install WordPress on a $5 a year shared hosting service, or as you said GitHub pages, so just convert WP to static files. I'm not big on WP but it just freaking works, and if it can generate decent static files, why not?
The key part about having your own personal blog site is owning your own domain. As long as you own the domain, you can change your mind. As long as you own your domain name, you can self-host today, host elsewhere, or whatever you want.
If the domain name is owned by somebody else, then they own and control the site, not you.
This brings up the related issue of the normal domain name system and it's governence. No one really owns their domains. They lease them at the whim of some corporate or government entity.
But if you put up a tor onion service you actually own your domain name. I'm not saying only host on tor, but why not a .onion too?
That is an endless rabbit hole. In that case, no one owns land or any other kind of property either. Obviously a government entity could take any or all of it away from you if you are in their jurisdiction. And if you do not pay land taxes, you don't get to keep the land either.
I mean ownership in the usual sense. There are laws and people who are supposed to enforce those laws so that once you purchase something and obey certain rules, you get to keep it. Perhaps more importantly, if a typical energy says they just want to take it from you, there are courts you can appeal to.
If you post on Facebook, and Facebook takes it down, you have absolutely no right of appeal. If I post material on my personal site on a domain I own, it is harder to take down, and much easier to bring it back. I'm assuming here that the content is not illegal, that's a different issue.
We host our blog using solely off-the-shelf tools, and I love the stack that we use. I highly recommend it if you're looking for a stack with 100% control and are ok with some light technical wrangling (eg using Git):
- We use the Hydeout Jekyll theme, you can see how it looks on our blog: http://staysaasy.com/. What you see is out-of-the-box plus ~30 lines of custom CSS.
- Git for storing our content
- Gitlab for CI/CD and hosting
- GoDaddy for domain management
We manage all of the content in Git, and push it when it's ready. It's really easy. You can even run "code reviews" on posts if you like.
Just because it's what we already used. It's the most dispensable part of the stack (and arguably shouldn't even be considered part of our stack at all).
Very true. In the setup listed above we use Gitlab for hosting and it's 100% free with a fairly non-technical interface. If you're going for static hosting of raw pages Netlify has a folder drag&drop hosting option that's great as well.
I use Hugo (https://gohugo.io/) to generate static pages and host them on Amazon S3, with CloudFront on top of it for fast delivery. AWS also provides a free SSL certificate, and DNS with Route53.
I couldn't be happier with the setup: it's cheap, fast, requires zero maintenance and pretty much never goes down. Cost is close to nil: the most expensive part is for Route53 at $0.50 per Hosted Zone, and then S3+CloudFront add a few cents more.
If folks want to see how fast static pages can be on a CDN, the site is at https://re.kv.io
The only problem with that setup is if a post goes viral CloudFront will cost you a pretty penny. I had one post with ~1MB of assets that was read (IIRC) 70k times in a month and got an ~$80 bill. I’ve since switched to Cloudflare.
The AWS Calculator[1] reports that 70 GB (70k times 1 MB) of transfer out of CloudFront costs ~$3 and another 70 GB to the origin costs about another $3 – this would only be the case if the 1 MB was dynamically generated.
The free tier is 50 GB and 2 million requests per month, and beyond that it’s ~0.085/GB in the US so 70 GB would cost 70 * 0.085 = $5.95. You also need to count $0.01 per 10k HTTPS requests, or $0.07 for 70k.
I'm not sure how you got this bill, none of these numbers are anywhere near $80.
OK, I was off quite a bit and the total of all assets on the page is 27MB. That's mostly due to several HD pics on the page and one 2-second soundless looping MP4.
The total CloudFront bill was $87.65, the bulk being $74.98 spent in North America (2.5M requests @ $2.52, 852.518 GB data transferred @ $72.46). Those prices are as of March 2019. Doing that math that's only 31.5K page loads in North America (my 70K view number is from Google Analytics worldwide and may have straddled months, or counted re-views, I dunno).
Now, I remember running those pics through TinyJPG so they are as compressed as possible. And I could probably add some kind of JavaScript lazy loading library to only load images as users scroll down to them. Or, I could just use Cloudflare and not think about it. /shrug
If you're just hosting purely static assets why not use a free hosting with GitHub pages and a custom domain? It comes with free SSL (now) and I assume it could handle all sorts of traffic spikes. I might not be aware of any major downsides so I'm curious why people decide to use a paid (even if it's super cheap) option. I believe also Gitlab offers similar options.
I've had poor experiences in the past with GitHub pages, with pages failing to build or hosting being terribly slow. This was years ago though, things may have changed since then.
That said, I can still count 9 occurrences of degraded performance for a total of 16 hours and 40 minutes in the past 90 days for GitHub pages on https://www.githubstatus.com/ – as a matter of fact performance is shown as degraded right now. That's pretty terrible.
Also if y'all are looking for incredibly cheap servers https://www.serverhunter.com/ has many listed that are less than $5 a year. Most of them are OpenVZ based, and very low performance but good for hobby projects. The other compromise is many don't have entire IPv4 addresses, just a few forwarded ports.
This doesn't cover IPv6 - you'll also need to create an AAAA record and (presumably, not familiar w/ Caddy) bind to an IPv6 address (e.g. ::1) in the reverse proxy config
I coded[0] a very simple CMS for my blog around 8 years ago. I wanted something fast and I wanted to use python instead of PHP. so I went with nginx + uwsgi. The website[1] runs on an old laptop. 8 years later I've edited maybe a handful of lines of code.
Perhaps I'm missing something, but I don't get why these articles pop up so frequently as if making a blog was some super complicated thing that required the latest CMS, etc. Most people here (including me) would suffice with a nginx and plain html/css, no CMS required, based on articles like these, at least.
I’ve wondered the same thing. It’s so ridiculously convenient that there has to a catch!
I previously used the S3 + Cloudfront setup that many commenters have mentioned, but have switched to Netlify for static sites simply because I don’t have the overhead of setting up any configuration in AWS. With Netlify, you can be up and running with a new static site as soon as the DNS record propagates.
I’ve always wondered if there was any throttling or performance impact at high traffic- but I haven’t built any high-traffic sites yet :)
> Wordpress is bloated. It won’t even run on a basic free DigitalOcean instance.
Woah, does it use an obscene amount of RAM or what? It's been a while since I used it. (Also, I think you meant the cheapest Droplet using the free $100 credit? I don't think there is a free tier. Would be nice tho :)
None of these alternative suggestions are. Nor is the blog post suggestion though, they're not running on their own server but a cloud providers. Sooo all of this is really not self hosted
If you don't use SaaS blog platform and host it on a VPS it counts as self-hosting?
In this case shared hosting will be even cheaper and maintenance free. System, server, Let's encrypt cert, database and language updates will be taken care of. Many of those PHP CMS-es or blogging systems have a one click updates in place. Some shared hosting providers can also take care of this for you. You can get something with ssh access and rsync so you can be lazy and edit HTML with Word and just sync it or an SSG if that strikes your fancy.
It's a single binary file, so there's not a whole lot to be gained unless you're already doing containers in general. When the entire system is this few moving parts, I'm not sure that it's worth the trouble of containerizing it.
Good stuff, but I never liked self hosting a blog when I can just pop it up on a hosted solution. I want to write and forget and not maintain. By the time that I setup a blog, I'd have lost my interest in writing.
Probably, I'll just write about my pain about how did I deal with docker, exposing the port, nginx reverse, some vps provider and DNS stuff.
Instead of:
The author probably just needs: That way "localhost:2368" will be routed to 2368 inside the container, such that caddy can access it, but not accessible externally, as it is right now: Though of course the ideal solution would be to run caddy as another container, and link them together.