Show HN: Netlify – Builds, Deploys and Hosts Your Static Site or App
netlify.com
netlify.com
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
Where is the proxy server running?
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.
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.
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.
Can you give us any hint of what you're thinking about?
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.
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.
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.
Want to kindly leave my feedback: I tried to upload using Firefox, and found that there are some friction with the uploads..
1. was unable to upload a single file, called "index.html"; the site asked it to be zipped, or worst to switch browser (that almost made me walk away)
2. zipped the file, and same error; was thinking this site is broken
3. I created a folder, dragged the file inside, compressed and upload.. and finally it worked!
Now that I know that I need to upload a folder, it seems right .. but it took me a while to figure
just my 2 cents :)
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...
This is my setup (minus CloudFlare for CDN). http://brooksgarrett.com/blog/jekyll-github-travisci-s3/
Is the value in simply abstracting away the (fairly technical) setup which would normally be a barrier for non technical businesses?
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.
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."
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?
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.
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.
If you follow us on Twitter/FB/Newsletter etc, you'll get notified when we're ready for that...
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 think you're done then :)
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...
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.
You should really change the slogan! I don't think it reflects what you are offering.
"Static hosting without the static"
"speedy, secure and simple"
"Home of the KISSSS principal. Keep it speedy, secure, simple and static"
"Save time and money while gaining ironclad security and speeding up your web service"