We also have walrus stickers! Let me know if you want one and we can mail it to you.
Thanks Nick! You can fill out your mailing address here and we’ll send you some: https://surge.sh/stickers/
well heck yeah I want a walrus sticker!
Awesome! Thanks Chase. Fill out your address here and we’ll send you one: https://surge.sh/stickers/
ohh ohh! I want a sticker!
Great! Here you go: https://surge.sh/stickers/
that is amazing. how could anybody not want one of those!?
Thanks so much Matt! Just fill this out and we’ll send stickers your way: https://surge.sh/stickers/
Here you go! Cool Twitter header, by the way. https://surge.sh/stickers/
Thank you Kenneth! I took that photo while visiting Nashville, TN. It was a wall inside Hatch Show Print!
Wow for some reason I thought that was a pair of legs in a green dress and the top part was just... not sure what it was
Now I see the walrus though!
Thats exactly what I was thinking! I didn't even notice it before they said it was a walrus. It seemed like a weird logo for a CDN.
We were going for a little out of the ordinary :)
If you still want some stickers, feel free to fill this out: https://surge.sh/stickers/
Here you go Trevor! https://surge.sh/stickers/
I would love a walrus sticker :-D
__ _ /oo\/ \ /(_X_) / / V-V ~--.__ /\ / ~--~ / (__/\_______________/
Wow. This is awesome! We might have to contract you to do some Ascii art for the CLI ;)
You can sign up for stickers here: https://surge.sh/stickers/
Yeah, hook me up!
Woo! Already rocking some.
Thanks again for having us by Unbounce! Definitely let us know if you have any more feedback. :)
Awesome, I'd love one!
Here you go, Simon: https://surge.sh/stickers/
I'd like a sticker too!
Here you go, Leon! Nice icon, by the way. https://surge.sh/stickers/
Yes, please! That's a great illustration!
Thanks Brian! Carter at Twilio has been has been helping us test Surge, we’ll send some extra stickers your way if you don’t mind filling this out https://surge.sh/stickers/
That's badass! I want one!
Here you go, Elliot: https://surge.sh/stickers/
Also, I see you’re into Angular! We’ve got a pretty cool feature for apps using push state that we’re going to be writing more about soon, I’d be curious to get your feedback on that sometime.
Sure! Shoot me an email at firstname.lastname@example.org sometime.
p.s. When you get the chance, I'd love a response to a comment I made down below with regards to a concern I have with Surge.
Awesome stickers! I want one :) Please :)
This has been the missing step in my development setup. You just saved me the hassle of creating my own CDN.
My one concern is...how is this going to be sustainable (you don'y need to use specifics). The thing that I am afraid of is creating a site that uses Surge today, and in three years when your funding runs out, all of my sites suddenly stop working. I try to use Google's CDN whenever I can because I know that they won't go down until the internet does, but it's hard to say for the little guys.
Is there any failsafe plan for if you go under? Even something like "We will eventually build an easy export tool so you can upload all your files to your own CDN?" would make me feel safer.
Thanks everyone for the positive vibes!
Kenneth, you better make good on the sticker promise :)
How about a pay-what-you-want type of pricing model?
This is great. Seriously. Thanks for this Kenneth, Brock.
If this is what it says it is, I completely love it!
We've been doing CDN hosting for static sites for more than a year now, and have both CLI tools, a public API and full web UI's.
Not sure how to put this without coming across as a bit agressive, but:
DO NOT USER SURGE FOR A PRODUCTION SITE RIGHT NOW!!!
I did some tests, to compare our products. And surge sets these caching headers on EVERYTHING including your HTML files:
This header tells any browser or intermediary cache, that it's ok to just keep a copy of the current file in the cache and use that for up to 1 year without ever checking back with the origin server.
What this means is that if you put a production site on surge right now: there's NO WAY to ever make sure your users ever see any changes you make to your site within the next year. Even if you move to another host and completely redo your site, users will keep seeing the current version of your site until it happens to get pushed out of their cache!!
Surge guys: make it super high priority to fix this! You can really, really screw some people over. If someone within a large company access a site with these cache headers, chances are their corporate proxy cache will store all the files locally and never check back with your servers until they expire... I realize it's a free product, but this could cause real problems for people!
Apart from that the current SSL support is vulnerable to several known attacks: https://www.ssllabs.com/ssltest/analyze.html?d=bite-sized-apple.surge.sh
Thanks for your feedback Matias. I wish I had seen this comment earlier as there is misleading information here. I'm happy to talk about it with you. Seems like an opportunity for us both to make our platforms better.
FWIW - We have used the same max-age/etag combo used to serve over 4500 applications over the past 8-ish months - with no reports of users experiencing stale caches. So it hasn't been an issue in practice. If we take a closer look at the HTTP1.1 specification we can see why.
Caching in HTTP has two basic components, Cache Directives, and Cache Validators. Its not uncommon to get these two confused but the difference is significant.
Cache-Control:public, max-age=31536000is the cache directive. This tells the client how long the asset COULD be fresh for and that it MAY store the file for that long it likes. In this case the maximum age is 31536000 seconds (1 year). This does NOT mean the asset is fresh for 1 year. It still needs to be validated before served.
In section 22.214.171.124 of the HTTP specification it describes the max-age cache directive as
The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.
ETag: "dee9f721409ef9b0e61188266eca494d"is the cache validator. This is the information that the client needs in order to know if the file that it stored (based off the cache directive) is still fresh or stale. The client does this by passing the etag back through the
If-None-Matchheader when it makes the next request. If the
If-None-Matchstill matches the etag the server responds with a
304, and extends the max-age another year allowing the client to serve the cached file. If not a match, the server reponds with a
200, the new file contents, and a new eTag for revalidating in the future. The result is any given file will only be distributed once (even with HTML files). This is a more reliable way to do cache validation though it requires you to have confidence in your eTags (in our case we do).
In section 2.3 of the HTTP specification Etag is described as a more reliable validator than modification date....
An entity-tag can be more reliable for validation than a modification date in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where modification dates are not consistently maintained.
Many CDNs use
Last-Modifiedas their cache validator which requires guesswork as to when the cache is invalid. So in reality, the opposite is true. If you want to be sure your users are never served stale assets, max-age/etag the more reliable approach. The
Last-Modifiedapproach could have less network requests though to compensate you cant cache HTML files. Personally, I don't like that tradeoff.
HTTP caching headers are a known to be ambiguous and I don't claim to know it perfectly but our approach is deliberate and according to the specification and our use in production I would say sound. There should be no concerns of being served stale assets ever - much less a year.
As for the SSL, we got that fixed. Thanks for pointing that out. Happy to send you some stickers to say thanks.
The plan is that everything that surge does today will remain to be free. Mainly, that is unlimited applications with custom domains.
I'm not sure if that's a good plan…
GitHub can afford to give away hosting for free, sure, but that doesn't make it a great business model.
I am wondering how this is going to be profitable too? Github hosts the projects anyway, so I can understand why they have free website hosting, but with Surge I don't?
Sacha G. Thanks for sharing your thoughts. Do you have any suggestions for what would make for a compelling paid plan?
2 cents: Charge for custom domains?
We actually support custom domains for free right now. This is such a crucial part of publishing real static sites and client side apps we didn’t want to limit you.
We’ve been thinking about this from other angles too, and definitely appreciate the feedback, though, so thanks!
Maybe look at https://divshot.com/pricing ?
Thanks for commenting Sacha, I’ve been reading your newsletter for quite a while and definitely appreciate the feedback. Custom domains are just such a critical part of publishing real projects we didn’t want to limit people from using them. We’re still thinking ahead too. :)
Anyway—if you’d like some stickers, I’d love to send some your way: https://surge.sh/stickers/
I love that the "landing" page is simply a cleverly created Medium Post - BIG thumbs up!
Seems interesting! I'll try it out on my next project.
Very aweome! Tried it but I don't get clean URLs though
Just tried it this morning, amazingly simple. Almost too good to be true, which is why myself and others are asking the 'cost' question.
I think everyone is asking not because they don't want to use it unless it's free, but because it's good enough to be paid for. A services that allows me to bust up a live site in a couple of commands is worth the money, at a reasonable price of course :).
I'm also worried whether this CDN would be sustainable. I usually use http://cdnsun.com/ and upload all my files to my own CDN, it makes me feel safely. But it's useful to diversify the CDNs.