Thanks, really happy to see this is the officially recommend approach.

I've been doing it, but got some uncomfortable knee-jerk reactions from other developers, e.g. "But you should NEVER serve static assets directly!!!".

...but it's only served once!

> e.g. "But you should NEVER serve static assets directly!!!".

As with music, painting, and architecture, any development-related NEVERS require that we understand the why, so we can know when to break the rule.

Isn't this still problematic with SSL? Last time I checked, you had to pay $600/mo for a custom CloudFront SSL cert if you wanted to pass through the credentials from your own domain.

(Using mixed http/https was not an option.)

It's true that this is a problem if you insist on serving your CDN assets a custom domain CNAME mapped to CloudFront (i.e. https://assets.mydomain.com/). It doesn't cost extra if you just use the default CloudFront distribution URL, i.e. https://d3vam04na8c92l.cloudfront.net/stylesheets/applicatio...

This is not entirely clear from the Heroku docs, I'll ping the maintainer for an update.

One cool trick for serving mixed http/https that I somehow went 10 years without finding out: you can just point your Rails asset_host to "//d3vam04na8c92l.cloudfront.net". Browsers understand this to mean "Look up this address via whatever protocol I am currently on, http if http, https if over SSL."

This is a huge cache boost in Rails because you don't have to cache your pages twice (once for HTTP once for HTTPs.)

Oh god.. While your post is cool, I reacted violently to the "One cool trick..." part at the beginning.

Upworthy, you've broken me.

Is there any real downside to this approach, or is it just that it looks "less professional"?

No, you're still serving the same assets. It's only really an issue if your users like seeing where network requests are going and spot the cloudfront URL.

Does Google have something like CloudFront for Compute Engine? Google gives you edge-cache for free if you use App Engine, but what about GCE?