Wel we can have gathered most beautiful website, if it’s not possible for people visiting it, then it’s useless.

Publishing content is what this is all about in the first place.

You can be the greatest writer that never got published, the best painter of your generation that has no space in an exhibition, the best singer songwriter that has no audience. If you create, you need to get your stuff out there.

That also means being vulnerable, receiving feedback, good and bad, dealing with all that.

But lets cut to the chase. Like I said before, I’m old school and technically publishing content on the internet for me starts with finding and registering a good domain name.

A catchy name, that can be easily remembered, and is meaningful to you.

There plenty of cheap domain resister services that will hep you look at the available ones, and register them for cheap (depending on the TLD, Top Level Domain, like .com, .org, .co, …)

Historically and since the early 2000, I am using the French/Polish OVH, that offers convenient, cheap products for ‘geeks’ and DIY internet nerds.

Since the last couple of years, I’m also starting to use AWS, with their specific services for publishing.

I have toyed with both, first with OVH and the simple, straight forward and insecure FTP service to the ‘webroot’ to upload the generated static files from Hugo. The second option was much more interesting and was having AWS Cloudfront, serving static files from S3 buckets.

Both are easy enough to set up, and both allow for basic ‘configuration’ via a web interface, via an API or in the case of AWS a template/stack.

So I have this site hosted on AWS via Cloudfront, files hosted on an S3 bucket, domain name registered on Route53, certificate managed by AWS Certificate manager and having an alternative name with www. added. Also the template/stack allowed to have a Lambda function set up so that the site would enforce HTTPS (what you want to happen always), but more on that later.

Forestry offered ‘deployment’ service before, allowing the site to be build/generated and then pushing the resulting files via FTP, SFTP, S3upload on a place to serve them on the ‘net. Unfortunately, they stopped doing this (for obvious reasons), and hence pushed towards even more developer centric setup, including a CI/CD pipeline.

So for all sites I had to set up a CI/CD pipeline in an automation tool of choice, in this case the widely popular CircleCI.

In any case about half a day of hacking, tinkering and cooling stuff together go me in a setup that allowed me to easily adapt and edit content via MarkDown and a human friendly UI/UX, that published as soon as I pushed the button on a worldwide CDN, making this the fastest site I have ever published, available anywhere on the internet and around the globe.

https://Subite.io was born

• website
• hosting
• cloud