I'm not a paying customer of or affiliated with Surge—just a happy user.
Surge is what I've always wanted to when I do frontend development for fun and learning. This is especially true if you're new. When you're new, you don't want to set up a server to push to Heroku or Digital Ocean, you may not want to use GitHub pages, or other alternatives (not aware of all, just the ones I mentioned). You may still be new to git and git-based deployments.
Surge is simple: `surge -p build` will upload the `build` directory and give you a nice HTTPS URL to share with your friends. `surge` does the same with the current directory. You can pick a URL under their domain or use one you own. It all takes a few seconds. Perfect for portfolios, demos, etc.
If you use npm you can `npm install --save-dev surge` and add a script that does your production build step and then calls surge to deploy it.
I'm still confused what this service does. `surge -p build` and `npm install --save-dev surge` is simpler for a newbie than getting sftp credentials to a shared host? My designer friends can drag and drop, but certainly stay away from the console.
Nice service, but too expensive to be honest.
My static websites (built with middleman) are hosted in Amazon S3 as a static website bucket and have a Cloudfront distribution in front of it. I use `middleman s3_sync` to deploy the build in one command and it takes care of everything, even Cloudfront invalidation. All for just a few pennies per month.
We are still figuring out our pricing. It kind of kills me to hear someone call surge too expensive. We worked hard to give surge a very legit free offering which is serving over 35k projects. Surge gives (currently) unlimited projects with custom domains. We charge $13/mo for that extra 1% which is custom SSL, basic auth, custom redirects.
Very open to suggestions if you have any. Would you prefer we have a small membership fee and open up all the features? What would you suggest is fair?
$13/mo is pretty good for people with premium requirements (as you said, the 1%) in my opinion.
Though, I feel a psychological bias for paying upwards of 10 USD for services, since there are so many of them. I feel comfortable paying 9.77 USD for Netflix (India), but 12.6 USD tier just feels expensive.
We use surge.sh to host our production app for our customers, and have been very happy except for one bout of downtime which was very frustrating.
I have no objection to paying 13$/mo if surge would implement some premium redundancy features. Cloudflare already gives me the SSL I need, and 13$/mo for custom redirects isn't really worthwhile for me when I can just use hash-based history for our app.
Basically I think you guys have the pricing worked out incorrectly, at least for our use-case. Avoiding downtime is the #1 reason I would pay someone else to host something for me (because tbh I can just write an ansible script to deploy my code to nginx running on Digital Ocean if I wanted to maintain it myself).
It's too expensive when you have multiple small static websites. I could host several of those on one DO droplet for $10/month, but with surge it will cost me $40+/month for 3+ projects (I do want SSL for my custom domain).
I gave up on Middleman when I couldn't get anyone in various Ruby mailing lists and IRC channels to advise me how to stop Middleman deleting directories which aren't mirrored in the src directory. Jekyll has the keep_files: [] config option.
I wouldn't be too quick to say it's too expensive.
My set up is not dissimilar to your own. I'm comfortable working on the command line, using s3cmd to sync the site, modifying bucket policies, etc. Once you know those things - or if you enjoy learning them - it's all pretty trivial, but if you don't... well don't underestimate the hassle for someone who doesn't know this stuff. I'd think it a waste to pay $13/mo for what I'm happy to throw in an S3 bucket, but that's 3 venti lattes for someone not to have to deal with any of it. It's not the file storage they're charging for.
This is the same reason I ended up with S3/Cloudfront as well. A while ago, I was moving my site from GitHub Pages. I wanted HTTPS for my custom domain and more control over how my site was cached. I looked at Surge and, as much as I loved their defaults and CLI tool, that $13/mo price tag was too high.
"From now on, I think I'm going to strive to build all my apps as fully static sites."
What? I can understand the idea of not overcomplicating an app when you don't need to, but how does this goal make sense for anyone who wants to build anything non-trivial?
> This is the whole point of JavaScript frameworks to me.
What does it matter if your front endpoint is on S3 or being served by your own web server? Delivering static assets isn't that hard and you don't solve a lot by hosting the front end point of your app on S3.
Your bottleneck is way more likely to be your API long before static asset serving is a problem.
I understand the architecture you are describing, and I don't think that it is trivial. My confusion is over what really constitutes a "fully static" app.
IMO, static doesn't have to have a correlation to being simpler.
HTML, CSS, JS, and media are all static assets but you're welcome to request whatever datatypes you want behind the scenes via AJAX and/or CORs.
The benefits are entirely in the rendering speeds of an optimized web server and cache layer. Also, this approach plays extremely nicely with CDNs.
Difficulties can arise if you have to begin dealing with versioning of your assets to avoid cache invalidation, but that's what a proper build process can add to the static site.
In this particular case, my understanding is, the fully static code is just the frontend, in other words to not render HTML from your Web Server to the Browsers.
Indeed this is how I have build all my projects for the last two years. Currently I am building a platform to easily deploy a graphql api called https://graph.cool
Fully static sites don't necessarily mean static content in a user interaction sense. A lot of blogging platforms are database driven, but generate static documents instead of rendering the pages on the fly.
I agree it's a hyperbolic claim but it can work depending on the domain.
Did he perhaps mean build all his apps as single page apps? A react or angular site that uses ajax to load all data is, in some sense, fully static. This only applies if you consider the term "app" as applying only to the frontend part of your app. But that might make sense if your backend is all firebase or some other api.
No one is suggesting compiling a giant project like wikipedia into a static site and deploying to surge. its about the web client being a static front-end that can be cached and run offline.
+1 -- I use Stout all the time. I don't have to rely on anyone's uptime except AWS's. Stout's just a "shortcut" for using AWS infrastructure that I have full control of.
With Surge, I'd have to trust some startup's build tool not to fail at a vital time.
I don't work directly with Surge but the other developers where I'm at have found Surge to have too much downtime and we're moving off of it now. Maybe in the future they will have a more reliable service, but right now you'll definitely experience the growing pains of a new tool.
We are having growing pains no question. We have learned lots about our system recently due to some of these incidences. Changes are underway to make the system more fault tolerant and resilient to attacks.
Give us time to make things better and please keep us on your radar.
Very nice. Services like this can help keep the costs and maintenance of smaller projects to a minimum. I myself created a proof-of-concept online programming judge without any server (see http://www.pesfandiar.com/blog/2016/05/12/javascript-online-...). I only used Google Cloud Platform and Cloudflare at virtually no cost.
I wish they had some minimal features that you'd need a server for. I'd pay $5-10/mo to get some basic authentication, custom headers, and maybe even some sort of user-specific key-value store.
Love Surge so much. The CLI interface is stellar. We use it for testing feature branches of frontend code. Writing a tool to automatically spin up an environment for every pull request (alongside the CI). Helps the whole team test new features without having to pull down the branch and review locally.
I mean, if you're doing a static site you can also use github pages with a simple push command. Is there some difference between surge and doing this that I'm not seeing?
If you are properly preparing your assets for web distribution you really don't want those files in a git repo. it messes up your commit history and doesn't provide much value. I think gh-pages is fundamentally broken for this reason. IMHO its best to keep your source files in a git repo and publish your compiled assets to surge.
https://github.com/edgecase/middleman-gh-pages solves this problem by letting you do all your work on the master branch, then your build script compiles all your assets and commits them to the gh-pages branch, so it doesn't pollute your Git history.
I used to use GitHub Pages, but you can't have a custom domain that has SSL, so I switched to Surge like six months ago, and it works great. To be honest, though, if GitHub adds custom domains with SSL to pages, I'll probably switch back.
Have you considered Gitlab, which does advertise custom domains for which you can upload your own SSL certs? Even at the free plan level. I would switch to it if not for the fact that my site isn't dealing with any kind of sensitive stuff so I figured Github Pages with Cloudflare's SSL was enough, although I'm aware its not end-to-end.
I think your sites need to be "on" cloudflare (i.e., the cloud icon in the DNS settings page needs to be orange and not grey) for other features like SSL and Page Rules to work. Specifically for Github Pages I configured both my apex custom domain and my www subdomain to point to myusername.github.io. Cloudflare will automatically follow myusername.github.io and return the origin IP when requests are made to the apex custom domain, something they call CNAME flattening, and similar to the ALIAS and ANAME records offered by other DNS providers. Plus I set SSL as "Full" but NOT "Full(Strict)" as the latter won't work with Github Pages' servers. There are some anecdotal reports I've read saying that for some Github Pages sites even Full SSL doesn't work, so if that's the case you can try Flexible SSL which should work in all cases. And of course as the other responder said, don't forget to redirect all your http requests to https using a Page Rule along the lines of http://*mydomain.com/* --> 301 redirect --> https://[www].mydomain.com/$2
I do. I just enabled CloudFlare's SSL, added a redirect rule from unsecured http to SSL in CF (there is a template I think) and adjusted the base URL in the YAML file of the repo accordingly. I don't believe I did anything else.
The deploy process is much easier for me to manage on GitHub Pages, because I can just do "rake publish" and middleman-gh-pages deploys the site. Neither I nor my collaborators have to deal with the details of deploying. Surge makes you remember to call the surge command with the proper arguments and have collaborators also have surge accounts set up properly.
Maybe there's a way to have a GitHub webhook automatically trigger a deploy to Surge? That would probably solve this issue for me. Though GitHub Pages is still easier.
Interesting idea for making kind of a PaaS for static websites.
I have been using a Firebase Hosting [1] (provides free https, CDN, CLI publish with `firebase serve`) for a while. Obviously, Firebase quotas and pricing is way another but I am curious how do you compare Surge to Firebase Hosting?
I'm a co-founder of netlify and happy to chime in.
Surge is a simple tool with a really awesome CLI for deploying static sites quickly.
At netlify we're building a larger platform for working with a modern static approach.
We have an integrated continuous deployment platform. That way you just link a git repository to netlify, and we'll do the build whenever you push to git and even give you preview deploys of pull requests.
We run our own content delivery network, which means a lot for performance, and can post-process assets to automatically serve them out of a larger asset CDN with far future expires headers.
Netlify has built in Let's Encrypt support with a 1 click setup. We'll do automatic certificate rotation and enable HTTP2 when HTTPS is turned on.
Our CDN can handle complex proxying and redirect rules. If part of your site need to go to a dynamic backend or if you need API proxying, a one-line rule can set this up. We can even handle gradual migrations from a dynamic to a static approach by proxying all non-static requests straight from the CDN to a dynamic origin.
Apart from that we have lots of extra features like built-in pre-rendering for single page apps, Geo IP based redirect and rewrite rules, JavaScript snippet injection for easy analytics setup, form processing, etc, etc...
I came to mention PubStorm which I started using recently and have been pleased so far. I got the impression that some reasonable service would remain free?
As a web developer I feel sometime solution like that remove the understanding of how the internet works. This script can be replaced by a tiny shell script, that runs a rsync of the dev folder to your server, and I think it is important to know basic scripting like that even for a front end dev. I have to say that I haven't tried the script but I haven't seen anything impressive from the presentation video.
Along similar lines I have been playing with Bitbucket Pipelines and Hugo to build static websites on commit and deploy them to S3 buckets. Really like the way they use docker containers as build agents, it's very tidy: https://github.com/rabidgremlin/hugo-s3
Nice one! I'm a developer from Atlassian, it's cool to see the different CI/CD applications that Pipelines is being used for.
Regarding static site deployment specifically, Aerobatic (https://www.aerobatic.com/) have a similar static site publishing offering via a Bitbucket add-on, though it uses Lambda rather than Pipelines. They've got a couple of other nifty features like auto-renewing SSL certificates, too.
Brock from surge here. I would just like to clarify causes of our downtime because we like DigitalOcean very much and dont want people to have the wrong idea.
In the 1 year we have been available we have had 3 incidences each for different reasons.
The first was DigitalOcean taking us offline for not complying with a DMCA takedown request. This was before Digital Ocean knew who we were and they expected foul play. From this incident DO reviewed their policies on removing network access to customers and show genuine remorse for the downtime. Like I say we have been very happy with DO and would definitely recommend them.
The second downtime was due to user error on a bad deploy and the system unraveled in a sense. This was a result of several poor things that made the system more brittle than it should be. Somewhat significant architecture changes have happened as a result and more are underway.
Last, and most recently was two DDoS attacks on our floating IPs within days apart. Learning lots still about how to best protect our customers from this. System changes and mitigation plans are being put in place to protect our customers from these sorts of attacks in the future.
Wow! Thanks! It's not like I can just get it for free on any domain I like. Not even speaking about servers like Caddy that can do that automatically on launch.
Surge is what I've always wanted to when I do frontend development for fun and learning. This is especially true if you're new. When you're new, you don't want to set up a server to push to Heroku or Digital Ocean, you may not want to use GitHub pages, or other alternatives (not aware of all, just the ones I mentioned). You may still be new to git and git-based deployments.
Surge is simple: `surge -p build` will upload the `build` directory and give you a nice HTTPS URL to share with your friends. `surge` does the same with the current directory. You can pick a URL under their domain or use one you own. It all takes a few seconds. Perfect for portfolios, demos, etc.
If you use npm you can `npm install --save-dev surge` and add a script that does your production build step and then calls surge to deploy it.
Very underrated service!