Netlify is awesome--far and away the best option for static content that I've found, and very developer-focused.
There's a big list of pleasant surprises as you work with their platform:
* You can deploy a folder of static content quickly by just dragging it onto the browser window
* Better, you can set up continuous deployment with github and netlify will run your build command and deploy the result whenever you push to Github
* Even better, Netlify will install any needed dependencies from any Gemfile, package.json, bower.json or requirements.txt in the root of your repository, before running your build. Now you are open to a wide world of static site generators and build tools.
* There's a command line tool and a rich, well-documented API
* Clever: You can add a simple _headers file to define custom headers
* Great for migrations: a _redirects file can power some pretty complex rulesets
* Blew my mind: you can configure proxying so that external API endpoints appear to the browser to be coming from the same domain. This can greatly simplify the headaches around cross-origin resources.
Thanks for sharing these points, from a quick look at the site I couldn't figure out differences with GitHub pages.
Do you know how is the CDN working across the planet?
HTTPS & proxying look great! I'm hosting HasGluten.com [1] on GitHub and HTTPS is a big missing. Also, I'm using Google spreadsheet API (instead of a database) and proxying via my domain could be cool.
I was asking about the CDN, as one of the good things of GitHub+Google spreadsheet is (free) geo-distribution.
Our CDN is global yes. Actually, when you deploy to netlify, we'll fingerprint all your assets (CSS, JS, images) and rewrite the URLs in your HTML so we can serve those straight out of Akamai's CDN with a 1 year max-age.
We run our own CDN for the actual HTML files, currently we have edge nodes in 7 datacenters around the work. This CDN is super optimized to this use case, which means you'll get a 90%+ cache hit rate on your HTML from our cache servers, while still getting instant cache invalidation whenever you push a new deploy.
This is also what allow us to do more complex things like proxying, OAuth1 request signing and pre-render support directly at the CDN level.
We currently beat all the services we run regular benchmarks again in our internal benchmarks for real user performance.
Very cool stuff - question - on the website you mention: "Those that need a CMS (major exception we know, but check in with us regularly - we are working on something huge), and those that need constant updating."
Can you give us any hint of what you're thinking about?
A bit too early to drop a lot of details in public, but feel free to write me (mathias@netlify.com) and I'll be happy to share more details.
We want to solve the issue of having non technical content editors when working with static site generators, without having to rely on an external content-store (ie. content should still just be flat text files in your repository).
Right now the workflow for developers is amazing with modern static site generators. We want to make sure it's great for content-editors as well.
Tiny nitpick on the page: why does clicking on "pricing" in the menu take me to a page where I have to scroll over multiple screens until I actually get to see the prices?
We do the proxying straight from our CDN nodes, so it basically works like putting a CDN in front of the app/site you're proxying.
This also means you have an HTTP cache in front of the proxied site, so if you use HTTP caching headers like max-age or Etag we'll respect that and do conditional get requests to the backend or serve cached responses straight out of our CDN.
The proxies run on their CDN servers as I understand. I was just playing around with the proxy setup a bit to experiment, but I do plan to use this approach in a project if it proves successful.
I work at a digital agency (http://carrot.is/, hosted on Netlify), and Netlify has become our go to hosting solution for all our static projects. Their API is killer, but what we've fallen in love with most of all is the webhook support. That means we can use an external CMS like Wordpress or Contentful, load that data into the static site generator of choice (in our case roots: http://roots.cx/), and then send a webhook to Netlify to recompile the site every time content changes.
They've also been super responsive to any issues we've had, even proactively contacting us when a build fails with a solution in hand before we even noticed. Everything gets pushed to a CDN so our sites are as fast as they can possibly be. Happy to answer any questions from a customer POV, highly recommend these guys.
Very interested in this - and thanks for the detailed write-up on your blog on how to execute the Netlify/Contentful setup. One question: a lot of pages I work on are of the format "one big page" where you've got all the content on one page, with some navigation element to get you up and down the page. Basically the pages are divided into "bands" or "sections".
When I've tried to build these with static site generators (our current favorite is hexo but I'm going to look at roots), I've found that there isn't a good way to separate out content. We end up with the content being stored in .JADE files which are definitely not content editor friendly. I haven't found anyway to deal with this in a markdown file either. So we end up with a nice solution for the developers, but a poor solution for the content editor.
Do you have any approach to this using Contentful? Do you setup sections as individual entries, or is all the content for a page a single entry?
Lastly, how do clients feel about using Contentful? Is there any concern that they might go out of business? This is the common concern I hear with using anything other than Wordpress and would love to hear how you address it.
This looks great, and I would like to use it, but the pricing structure is frustrating. I help maintain a couple of static websites for small businesses run by friends. Since these are real businesses, the co-branding of the free tier is not viable, and $100/year is 3-4x more than we're paying for an S3 site. Low volume, I know, but if you are interested in that slice of business, there is likely a niche of people willing to pay for free tier infrastructure + no branding, and in my case also willing to make year-long commitments.
Sorry about that, should definitively improve the UI for Firefox based drag'n drop deploys.
Chrome is currently the only browser that supports dragging a whole folder directly into the browser and uploading that way (so that's why we recommend it).
We should make sure to change the copy for Firefox to make it obvious that a zipped folder is what works there...
How is this different from GitHub hosted source(Free), compiled by TravisCI (Free), hosted in S3($15/year), secured byand fronted by CloudFlare (Free).
Aside from a lot of technical details and extra features, caching details, performance tweaks etc, etc, the vision is the big difference.
Our big vision is to make static sites a viable mainstream alternative to Wordpress, Drupal, Joomla, etc, etc. Especially for all the people out there building sites professionally, whether they're agencies or lone freelancers.
Static sites are faster, safer, cheaper and simpler and for 90%+ of all the sites out there, they ought to be the default.
But you can't make static sites a mainstream alternative if the recipe for starting a new project is going to at least 4 different services and configure each of them, have plans with each of them, etc, etc. That's just a setup story that's so far behind just picking a Wordpress host and doing a new CPanel install that it's not even funny.
Our big goal is to make starting a new project with a static site generator just as easy as starting a new Wordpress based project. There's still some pieces of that puzzle missing, especially when it comes to collaborating with non-technical content editors, but we'll be presenting solutions to those as well.
Apart from that, typically people building sites or apps professionally have a pretty clear value put on their time, and simply having a one-click option that will setup everything and give you the best build/deploy and CDN performance, is typically easily worth the price whether they're building websites or single page apps.
I think that is a compelling narrative. I truly hope this takes off. I know several attorneys and other small shops that would value such a time saving service. The only major barrier is still getting them to design and publish the content. Solving that in the manner previous hosting companies made WordPress a one click install will be a major win.
After more reading you offer significantly more value than a pure static site with custom redirects and API passthrough. I just wonder about differentiating from CloudFlare.
The copy and layout worked to get me to click through and watch the demo (which I rarely do). The UX in the demo looked great. I liked the bitbucket integration as a feature and that it was included at the same level as github.
All of that interested me enough that I clicked through to see the pricing, so great landing page. I'm not sure if I'm the customer, but it did make me wonder, so who knows.
I did notice a typo:
"Your site is then automatically build & deployed."
Should be
"Your site is then automatically built & deployed."
This looks great. Definitely going to give this a test run this weekend.
A few questions:
* What are the advantages of having the build on Netlify's end vs. the approach used in Divshot (build locally then deploy)? (I imagine the answer is the same as why you would setup a build server for your compiled codebase - repeatable + reproducible builds, etc. Just wondering if there are other reasons I may not be aware of)
* What is the recommended workflow for setting up a beta environment and then promoting to a prod environment after testing? Would you use git branches for this?
Awesome, do let us know any feedback you have once you try it out!
You can do manual deploys (both from CLI and via drag'n drop) with netlify as well, and when you're prototyping or just throwing something online quickly, that's great.
However, once you're working on a production project, it's very nice to know, that at any time what's in the master git branch actually represents the current live version of the site. When doing manual deploys, it's too easy to forget to pull/push before deploying.
Apart from that, automated deploys opens up a bunch of new possibilities. Carrot have a pretty awesome post about using netlify with contentful (http://carrot.is/coding/static_cms), and we're using it to automatically update https://www.staticgen.com once a day.
For production/staging/dev envs, we recommend using branches yes. You can easily setup different sites to deploy from different branches, and the CLI tool have a -e flag as well, that makes it easy to work with different environments.
We have been using the Netlify service for the past few months (when it was just BitBalloon) and I must say it has been excellent. We have a handful of sites on the platform. All of them have preformed great with no issues.
The ability to host a static site with continuous deployment in less than a minute is amazing, along with all of the other great features mentioned. I'm excited to see what they produce for non technical content editing.
When setting up sites the support has been great. Mathias and the team have done a great job at building our trust.
How much of the stack will be open source? In the week after FoundationDB ceased to exist, there's still that nagging question of what happens when you guys get acquired. If the UI and deployment piece was open source and could be self-hosted it would make your own free and paid hosting + CDN more attractive by removing this concern, as well as open up revenue streams for supporting on-site enterprise installs.
I suppose technically the UI is already available given they give you the html/css/js in your browser (though perhaps not for redistribution, although this is a bit of thorny argument, given how the web in general deals with caching/proxies. I suppose if typekit can both give, and not give you fonts, a company can both give, and not-give you js/html/css).
Would be very nice to see this opened up with their blessing, though. Knowing that a viable self-host alternative exist, makes paying for the service (and supporting future development) a much better (and easier) business decision.
I'd liken this to Dabble DB that just disappeared when Twitter acqua-hired the team. Everyone (that wanted) got their data out, but couldn't keep their work flow -- which is a pretty expensive hit to take.
I recently thaught about the same thing... I'd integrate a lot of jekyll's architecture (or if you're .Net based Pretzel or Sandra.Snow), use Design blocks ( eg. Startup Framework which includes the online generator in the HTML purchase) and then a hosting which can dynamicly create the static sites.
Any idea how Netlify would work with an Angular single page app? I had a site hosted on S3 and ran into SEO problems because I could only configure S3 to do a redirect instead of a rewrite. The redirect caused the googlebot to drop the part of the URL and end up at the default route.
Works great with Angular SPAs. Our web UI is actually an Angular SPA hosted on Netlify and using our API.
You can easily setup a rewrite rule to serve your index.html instead of giving 404's so it works with history push state and we also just added support for integrating with services like prerender.io or brombone for SEO.
The last part is not in our docs or UI yet, but just write us and we'll get you setup...
We haven't actually started injecting it into free sites with custom domains yet, and we're still tweaking it.
The goal is a balance between something that visible enough that for profit sites will want to pay for a subscription, but discreet enough and pretty enough that it's not a big deal for hobby projects and personal sites.
I'm trying to think of a better slogan but can't come up with anything. What would you suggest that better reflects what netlify is offering? I'm probably too much of an engineer to cone up with good marketing copy! :)
There's a big list of pleasant surprises as you work with their platform:
* You can deploy a folder of static content quickly by just dragging it onto the browser window
* Better, you can set up continuous deployment with github and netlify will run your build command and deploy the result whenever you push to Github
* Even better, Netlify will install any needed dependencies from any Gemfile, package.json, bower.json or requirements.txt in the root of your repository, before running your build. Now you are open to a wide world of static site generators and build tools.
* There's a command line tool and a rich, well-documented API
* Clever: You can add a simple _headers file to define custom headers
* Great for migrations: a _redirects file can power some pretty complex rulesets
* Blew my mind: you can configure proxying so that external API endpoints appear to the browser to be coming from the same domain. This can greatly simplify the headaches around cross-origin resources.
* Bonus: HTTPS is supported