30
loading...
Jamstack Hosting Solutions: Challengers to the Throne
New to the Jamstack? Read this first.
When it comes to Jamstack hosting, two names typically come to mind - Netlify and Vercel.
Both companies have made a name for themselves in the Jamstack community for providing amazing features and services tailored to developers working in the space. But of course, they are not the only option, and as end-users of these services, the more options we have, the better it is for the community as a whole.
So here I am to help you have a look at 3 such "challengers to the throne" and hopefully give you more options to consider when deciding on the next host for your latest Jamstack site.
I'm going to host an incredibly simple Eleventy blog for each solution.
You can find the repository here.
I'll be looking into how easy it is to use each option, pricing, and available features.
Our options will be:
Let's get started and explore those alternatives!
Before we start looking at our options, a quick terminology check.
When talking about hosting options, you may hear such terms as CI and CD. These are short for continuous integration and continuous deployment. RedHat has a good description of CI and CD, but you can essentially think of it as a way to automate the deployment of projects tied to source control systems. So typically, this comes out as: I commit a file to my Jamstack site, and a process kicks off to build it and deploy the HTML. It gets more complex, but that's essential.
Lastly, CDN is short for **content **delivery **network. This, too, is a fairly complex topic, but you can practically boil it down to the deployment of your site (HTML, media, etc.) in a geographically performant way for your visitors.
To be honest, my only real knowledge of Cloudflare was as a company that does stuff with networking, CDNs, and so forth. I knew they did more, but they're not a company I've used directly in the past. Cloudflare Pages aims to be a "developer-focused" platform that makes use of Cloudflare's network to provide superior performance.
At the time of publication, their free tier plan supports unlimited sites, requests, and bandwidth. Pretty compelling!
The primary differentiator between their free and commercial tiers is the number of builds per month and the max number of concurrent builds. 1 build at a time and 500 builds per month on the free tier vs. 20 builds at a time and 20,000 builds per month on the commercial tier.
To start using Cloudfare Page's, you'll need to log in–not too surprising! But when I tested it, I did something... wrong. I'm not even sure what I did exactly, but I ended up in the wrong part of the dashboard and tried going through the wrong process. I guess that's my fault, but be careful. If you end up here, do not click Add Site, but rather Pages on the right:
Start a project, and you'll be prompted to connect to GitHub. Once you select a repository, Cloudflare will ask you for various settings. What's nice is that they have a large amount of presets. I selected Eleventy, and it correctly configured everything. (Cloudflare also has a large set of framework specific docs for more information.)
Hit "Save and Deploy" and the process and build for your site will begin. You get a pretty detailed display that updates in real-time:
Once done, you'll most likely want to test it. Your site's temporary domain name is found under "Custom domains". This is where you would also set up your real URL when you decide to go live, but the assigned URL is enough to check things out.
You can find my blog here
As the site is connected to GitHub, I could update it by simply pushing new content to my repository. I added a post, and a new build was fired off. It felt a bit slow to me for such a small site, taking three minutes to complete the process, but on the other hand, three minutes isn't even enough time to grab a cup of coffee. 😉
Cloudflare Pages support two interesting features for your projects–Cloudflare Access and Web Analytics. Cloudflare Access is a pretty deep set of access control policies focused on access to your deployments. Web Analytics is–well, analytics, obviously. But crucially, this feature is free for Cloudflare Pages users. If you use Cloudflare Pages, this data is collected with no change to your code.
The cool thing about this feature is that it's completely separate from Pages, so you can sign up for it and use it on your own site hosted elsewhere. While not documented, one of the first things I checked was the date range of the analytics. Netlify limits its analytics to the past thirty days. However, from what I could see (and again, this wasn't officially documented), Cloudflare's solution provides 90 days of analytics.
The stats are also more detailed than Netlify's solution, including important page performance metrics.
One aspect not covered by Cloudflare Pages is serverless. Cloudflare has a nice solution for this, Cloudflare Workers. Their free tier is very generous (one hundred thousand calls per day, that's three million a month!) but oddly limits you to thirty workers total, even on the paid tier. If you have a few workers supporting a site, let's say five, it feels like you can quickly hit the limit on the max number of workers.
Another issue is that your workers are separate from your main site project. So, for example, in both Netlify and Vercel, my serverless functions are bundled with the same repo hosting my Jamstack site. I like having everything together like that, but you'll need to have it in another repository with Cloudflare Workers.
All in all, it feels like Cloudflare Pages' biggest strength is in its generous free tier and its use of their CDN networks. While not as feature-complete as Netlify, it definitely feels compelling.
Signing up requires a payment method. I'm not too fond of this as a developer, and it's (usually) enough to make me walk away. They support both credit cards and PayPal, but if you use PayPal, they charge you five dollars. To be clear, that goes to your usage, but it means you can't use PayPal for a free test. Reluctantly, I went ahead and used my credit card.
Once you signed up, you're dropped in a dashboard that's probably one of the prettiest I've seen. Not that it matters, but it was impressive enough for me to snag a screenshot:
I selected "Host a website or static site" to get started. The next page had a variety of server-based options, like WordPress. I almost missed App Platform as it was beneath the fold.
After that, I selected GitHub as a source and my repository containing my Eleventy blog. And then it "broke"–I somehow ended up back in the first step asking me where to get my source. I selected GitHub again, and I figured out what the problem was. The first time you select GitHub, it walks you through the authorization process.
Once done, it brings you back to where you were. I honestly thought it was broken here. Their dashboard should (from my point of view) recognize the "return from authorization" flow and bring you into the GitHub process automatically. Just keep that in mind if you give it a test.
The next step asks you to configure the project:
The first thing you need to tweak is "Type". Change it from "Web Services" to "Static Site". For the build command, I use
npx @11ty/eleventy. Finally, I set the output directory to _site. The next step prompts you for a name and gives you a default domain. I left everything as is and hit Next to continue. The final step asks you to select a pricing plan and default to Starter, the free tier. Finally, you can start the build process. The first build seemed to take a little while, perhaps five minutes or so. I say "five minutes or so" because while I could find a log of my deployments, I didn't see a firm record of how long it took. (There are logs, of course, and you could look at the first and last to figure it out manually. From what I can see, my second build was significantly faster, which is good to know.)
You can see the live site here
And as far as I can tell... that's pretty much it. To be clear, Digital Ocean has a large set of features, but in terms of Jamstack specific features, I do not see anything in particular. Of course, you get things like automatic deployment when updating from GitHub and HTTPS. Still, all-in-all, this particular option feels more like it would be useful for people already using Digital Ocean for other more intensive projects with containers databases and storage. In that case, I could see having one particular vendor to cover all your deployment needs being pretty handy.
If my only need was Jamstack hosting, this option wouldn't be my first pick.
Microsoft's foray into the Jamstack world went live on May 21, 2021 (after a public beta period). Azure Static Web Apps is part of the greater Azure platform, making it a great addition to developers already in that ecosystem. Their pricing tiers include a free and paid tier, with the free tier looking pretty extensive. You get one hundred gigs of bandwidth per month and a half gig of storage.
Their docs take the approach of asking you which framework you're using:
Right away, you'll notice Eleventy isn't there. It does mean we'll have to figure things out a bit on our own. I started with the generic Web option. The Getting Started doc detail the requirements, which include GitHub, Azure, and Visual Studio Code, specifically an extension for Visual Studio Code. The guide kind of assumes you are starting from scratch and not using an existing site. You can skip to the "Create a static web app" part where you start working with the Visual Studio Code extension. Note that while Microsoft's solution is out of beta, the extension is marked as "Preview".
With my Eleventy site open in Visual Studio Code, I used the Azure icon to start the process of creating my app. As stated above, you will need a valid Azure account and be prompted to sign in when you begin.
Azure offers a free trial. I had signed up for one some time ago, so I had to set up a new "Pay As You Go" subscription. I found Visual Studio Code to be a bit–quirky with this process. It realized I didn't have any subscriptions but didn't update after I recreated my "Pay As You Go" service. The refresh icon didn't seem to do anything. I had to close Code and re-open it, and even then, it acted a bit weird. (See my tweet for an example.) I got it "connected" properly, but be prepared to restart. Even after selecting my subscription, things seemed a bit off. It got locked into a verification process. I will admit, I clicked the button a few times and ended up with this:
I guess all of this comes back to the fact that the extension is marked Preview, but with the feature itself being marked GA and with the extension seemingly being the only documented way to use it, this seems like an oddly broken process.
I closed Code a second time, tried again, and was able to continue with the process. After specifying a name, it then prompted for a project preset:
I selected custom. When prompted for where my application code was, I selected
/ (in cases your GitHub repo has Eleventy in a subdirectory, this is where you would care to change the default). The next step asked for the output directory (_site). At this point, Code started doing... stuff. I got updates in the bottom right corner letting me know things were executing, but it was mostly a waiting game. I knew that I had never entered an Eleventy specific command, but I assumed I'd be left with a bad build. Instead, I never got past this:
There was no way a Git pull on my source repo could take that long, so obviously, something else was up. On a whim, I expanded the Azure icons in the left-hand panel, and here is where I saw what I had expected, namely a failed build:
My guess is–the build failing was never communicated to other parts of the extension; hence, the progress meter "stuck" at the Git pull. It turns out the problem was incredibly easy to fix. To clue in Azure on how to build the site, I simply needed to add a
build script to my package.json:"build":"eleventy"As soon as I committed, Azure began the process again, and I was able to see it in the panel. By right-clicking on my site name, I was able to open the site in a new tab.
While the process was a bit rough via the extension, Azure does let you go through the same process via their portal.
Using the portal, things worked much easier. It's possible the docs mentioned this as an option, but it's definitely clear Microsoft wants you to use Code. Generally, I'm totally behind that, but, personally, I would have rather used the portal.
You can see the live site here
As much as I had trouble with the extension, by adding the Azure Functions extension, you can add a serverless endpoint to your site in seconds. I was stunned by how well that worked. Even better, it becomes part of your repository (you can see it in my /api and lets you quickly work on both your static assets and serverless functions together.
In the end, as with Digital Ocean, I think the biggest attraction for this option will be developers already making use of the Azure platform.
As the Jamstack continues to grow in popularity, you will see more options become available and greater differentiation between the options. Jamstack hosting for existing platforms (like Azure) is a sensible iteration. It appeals to existing users and offers a compelling upsell to newcomers. We should also see more "Jamstack first" options (like Netlify and Vercel) over time.
For another great look at hosting options, see this article from the Bejamas blog. I also strongly recommend signing up for the New Dynamic on Slack. It's the premier Slack organization for Jamstack and a great way to get honest opinions and help from engineers working on the Jamstack ecosystem.
Have you tried other hosting solutions for your Jamstack websites? Let us know in the comment below!