I am Sandeep, co-founder of Hashnode. I am super excited to be here and share what we have been working on.
Hashnode helps developers start a personal blog on their own domain for free and find readership from an active dev community.
We realized that traditional publishing platforms offer visibility and engagement at the cost of content ownership. On the other hand if you go with a self hosted solution, your articles don't get proper visibility and reach. Hashnode combines the best of both worlds. It lets you map a custom domain and publish articles under your own branding and also distributes them to a built in developer community.
We launched in June this year and have been growing 30% in different KPIs month over month. So, it has been a crazy ride so far.
If I already have a working blog that I'm happy with, would you suggest I look at Hashnode in addition, or is that not encouraged?
Having my own self-hosted blog is useful, it works well and ties into my existing site & tools, so I don't really want to change it. I'm just wondering if you'd recommend syndicating to hashnode as well, and whether that's well supported (canonical headers etc etc). I know lots of people syndicate their own blogs to Medium to widen their readership, and frankly getting similar benefits that without having to use Medium would be a big win for everybody!
I am Sandeep, co-founder of Hashnode. I am super excited to be here and share what we have been working on.
Hashnode helps developers start a personal blog on their own domain for free and find readership from an active dev community.
We realized that traditional publishing platforms offer visibility and engagement at the cost of content ownership. On the other hand if you go with a self hosted solution, your articles don't get proper visibility and reach. Hashnode combines the best of both worlds. It lets you map a custom domain and publish articles under your own branding and also distributes them to a built in developer community.
We launched in June this year and have been growing 30% in different KPIs month over month. So, it has been a crazy ride so far.
> Will AutoSSL also provide a way for the customer to login and provide them instructions on how they can set up the domain on their side?
Yes, I expose two APIs - add and delete. When your customer adds a domain, you can hit our API to whitelist it. The API responds back with CNAME instructions. Your app just needs to pick it up and display it to the users.
> What are the proxying limitations? Does it support Websockets? How much load can it handle?
I have 5 servers right now that handle TLS and fetch content from the origin. I just did a load testing with about 20K requests per minute, and it did fine. Will do more tests as I move forward. But before doing anything just wanted to know if anyone is actually going to use the product. :D
We have actually been using it for our existing product https://hashnode.com/devblog. So, I thought why not let everyone use it? That's when I spent my weekend coding an app that lets customers sign up and add their domains. :)
Hi.. The TLS is terminated at the edge, and from that point we fetch the data from origin server. As long as the origin has SSL, the communication is secure end-to-end.
>As long as the origin has SSL, the communication is secure end-to-end.
It cannot be secure end-to-end, as your edge location is quite literally performing a MITM. That aside:
How are you validating the TLS cert that the origin presents?
Going by the info on your website, the possibilities are as follows:
Scenario 1: The SAAS provider presents a TLS cert not valid for customer-domain.com when accessed as customer-domain.com
Scenario 2: The SAAS provider presents a TLS cert valid for customer.saasprovider.com when accessed as customer.saasprovider.com
Assuming scenario 1, you would need to validate the certificate out-of-band as the traditional trust chain does not validate for the given domain.
Assuming scenario 2, you would need to rewrite the URLs from customer.saasprovider.com to customer-domain.com to prevent the users from following generated resource URLs to the origin domain.
Or am i missing something?
the "end"s are the _browser_ and the _origin_, and if there isn't a single secure channel that goes all the way between them, that's not "end to end".
I mean take the "piecewise" argument to its natural conclusion.
If the reason it's okay for you to be in the middle is that you're going to ensure that your request to origin is also encrypted, why should you be the only party in between that can decrypt the contents of the connection?
Why not let the ISP also decrypt the contents? What about the layer 3 interconnect providers? How about your cable modem and your router (they're _probably_ patched 'enough' that it's safe to let them see your plaintext).
I'm harping because misuse of the term "end to end" is _actually dangerous_ to real people.
All of this is to say nothing of the fact that when you allow "middle-boxes", the client no longer has control over the ciphers that are used for the end-to-end connection, so they lose control over perfect forward secrecy.
Creator here. While building my current startup, we had this requirement to offer custom domains to our users. We also wanted to serve those domains over HTTPS. After days of searching and brainstorming, I had no luck! I found a couple of potential solutions but they were either too expensive or too complicated.
So, I spent a few weeks building an in house solution that automates the whole process of provisioning and renewing SSL certs for our users. It involves Let's Encrypt and has been working great so far!
Last week I thought of offering this as a SaaS product. With the help of my friend, I coded an app where customers can add their domains in a few steps. It's live at https://autossl.co. Once a domain is added to our system, we generate a CNAME record for that domain. When the domain is accessed for the first time, we generate an SSL cert on demand through Let's Encrypt and renew it every 3 months. I also expose APIs to add domains to our system. So, if you are a SaaS company offering custom domains to your customers, you can completely automate SSL issuance in an easy and cost effective way.
I think it has got some potential. What do you think?
I am using Caddy internally in fleet mode and Node.js. Caddy takes care of SSL negotiation, provisioning, and renewals. My Node.js app sits behind Caddy and proxies requests to the origin. I am trying to create an edge network where SSL is negotiated at a location that is closest to the users. Caddy is battle-tested, but managing multiple Caddy servers, monitoring them and backing up the certs can become cumbersome. That's the reason I am trying to automate the whole process for businesses.
We are still figuring it out. We will most likely have 4 tiers with the highest tier offering unlimited domains. We are thinking of pricing the highest tier somewhere between $400 - $500 and offer discounts to startups with < 10 employees.
Note that this is not final. I haven't given any serious thoughts to it. We'll discuss pricing if this works and businesses are willing to pay for this service. At this point, this is just an experiment.
You should have spent a couple of minutes instead of weeks to use something like Lego, certbot or even Caddy, which makes it fully automatic. Sorry, but you wasted weeks reinventing a worse wheel than what already exists.
