Ness – Deploy web sites to your AWS account | Hacker News Reader

Ness – Deploy web sites to your AWS account

ness.sh

87 pointsreimertz37 comments

The bottom of the page is a bit misleading. Having AWS logo while it's not an AWS product, followed by a tweet-testimonial (not marked as that) from a person working at AWS (marked as that).

Although not listed on the pages, it also supports 'destroy' command to unpublish, which is good. Otherwise fees from these small deployment can accumulate.

Fwiw, the testimonial wasn't a tweet; Elad gave it to me directly (in Slack IIRC). And I wasn't trying to make it appear to be affiliated with Amazon/AWS, but I see now how it could be interpreted that way!

I think this is a pretty bad starting point - static sites are basically free with Cloudflare/GitHub/Gitlab Pages all providing completely free offerings, making AWS a non-starter for hobby projects due to the costs involved.

This isn’t for static sites deployment.

Actually, no, this is for static sites deployment, it says so in the README. Only Next.js sites use Lambda@Edge, everything else is an S3 website.

My mistakes. Just realizing this.

Really? I've run several websites on CloudFront that got more than 100 visits per day and they didn't even break out of the free tier. I hosted something else that served 10x that and it cost like 16 cents per month. I don't think there is anything anywhere that is as cost effective as CloudFront!

Edit: Actually, right now I'm hosting around 10 small websites completely on the CloudFront free tier on a single AWS account, and I'm using the lambda free tier to handle all the redirects for them as well (i.e. SEO and www to non-www).

There are virtually no costs involved here, for the vast majority.

Free tier is 50 GB of data out a month and even the most expensive traffic data out after that is $0.12 per GB. For most sites the domain name registration is likely to be the biggest cost.

But it's free for first 12 months only.

AWS amplify provide this with automatic previews on github.

https://aws.amazon.com/amplify/hosting/

Any reason to use Ness over it?

Just looking around at both, there's two main differences. First is the Next.js support right off the bat, Amplify has Lambda support but doesn't optimize automatically. Next is that this is much cheaper. Building isn't done on AWS so using something like Github actions saves you the $0.01 per build minute. Amplify offers 15gb free bandwidth with $0.15/gb in paid version. CloudFront offers 50gb free bandwidth and no more than $0.12/gb. In certain cases Amplify is a better fit but Ness has its place.

Thank you very much for this answer! That was my #1 question (why this instead of Amplify) after reading the headline and you provided an informative, succinct answer.

Looks great. Configuring these sort of static sites on AWS takes quite a bit of clicking around the console so wrapping it all into a nice CLI seems like a great idea! I will be trying it out!

For those that are asking, I think you will just pay for the Route53 Hosted Zone initially which depends on traffic but for almost everyone will be about $0.50 a month roughly.

Interesting! I wonder how it compares to Cloudflare Pages, specially regarding updating a page after it has been deployed, and how easy it might be integrating it with Github.

It's unclear from the readme whether this supports Next.js's Incremental Static Regeneration (https://www.smashingmagazine.com/2021/04/incremental-static-...) that talks to the CMS every X seconds, diffs for changes, and rebuilds only the affected page if it detects any. It makes Vercel a lot faster at updating pages than Cloudflare Pages (which, by default, is only a static page server and doesn't do ISR... though maybe it's possible to hack Next.js to use Cloudflare Workers to do that instead, not sure).

Vercel is a lot more expensive than either Cloudflare Pages or Amazon Cloudfront.

It does not support ISR yet. If Vercel's price is a concern ($20/mo), you can always self-host. ISR works with `next start` out of the box.

For multi-container workloads with autoscaling or persisted cached entires to static storage, you'd need to write some code on the hosting side. Vercel is handling that piece for you, plus adding you to rollback and not lose your previously generated pages.

I believe they're working on ISR support, which is awesome!

Thanks for the insights!

Re: Vercel, it's not the $20/mo that's expensive, but their exorbitant bandwidth and serverless charges once you scale to actual production usage. Their plans are great for hobbyist projects that fall within fair use limits, but it gets really expensive to scale up past that. Their CDN cost is something like 10x what Fastly (their underlying backbone) would charge you directly, and a lot more than Cloudfront too. I mean, I get that they have to make profit, but they don't build their own infrastructure (mostly Fastly and a bit of AWS, I believe).

I don't think there are any other hosts that have out-of-the-box support for 100% of Next.js's features (ISR, image loaders, page rewrite rules, etc.). A lot of it only works by magic and only on Vercel. Would love to see Ness keep evolving, and especially if it supports infrastructure other than AWS.

100% Next.js support on Cloudflare would be the holy grail, with an unmetered CDN and super fast, super affordable serverless workers (albeit JS only, no Node).

Author here; would love any feedback and especially pull requests! :D

I made Ness for me, and continue to shape it around my needs, but I'd love to see that others find it useful.

I view it as an abstraction on top of web deploys, standing up all of the boilerplate stuff you need when deploying web projects.

Also, I'm adding Next.js ISR support as I type this.

Just built something similar - but as a CDK component (not a CLI):

https://www.npmjs.com/package/@updraft/aws-static-site-https

It also supports DNS entry, HTTPs only, SPAs and static builds (e.g. from hugo).

Nice, I use github to manage my websites/ssl but if the traffic gets heavy I'll use this!

What is the no-traffic running cost of this (or running any website on AWS)?

This is awesome! I’ve been using Vercel for awhile but will give this a shot.

Lately I’ve been trying to consolidate services in my life and this looks like it could help consolidate a lot of my side project web work to AWS

I'd like to see a list of what actual AWS resources it deploys

I think you mean something human-friendly on the marketing page, but if you are comfortable with Cloudformation YAML templates, you can find all the resources here: https://github.com/nessjs/ness/tree/main/static/stacks

It's in the readme

the homepage needs this info

or a prominent link to "docs" (which could be just a link to the readme)

Does anyone have a good way to use this to replace preview? My only idea is up on pull request down on merge.

Doesn’t AWS Amplify basically do the same thing? That’s how I deploy my static site

What is the difference of Ness over Qovery?

Ness doesn't use Kubernetes as far as I can tell, nor does it limit # of environments. It also seems to only work on AWS.

I'd love something like this but for docker. I know of Qovery but I've had problems with it, and a CLI application would be better

What is it? I can deploy a web site with FTP.

Not a lawyer.

I seem to recall that setting this to a year other than the correct one can affect copyright.

Set it to the last modified date, not the current year.

If you dynamically set this to the current year, you’re doing it wrong.

The copyright notice is there to indicate when the copyright started; i.e. when the creative work was first fixed into a tangible medium. If you created something in 2020 and you tell people that it’s copyright 2021, you are in essence cheating to get an extra year of the already absurdly long copyright period. If you created something in 2020 and then modified it in 2021, then use a range of 2020–2021.

The copyright notice is not there to tell you what the current year is. What would the point of that be? Everybody knows what the current year is.

Fair enough but using a single year doesn't make sense in the context of websites at all then. Following on another question I have from this is why is a year sufficient? Is it the 1 Jan or 31 Dec? that would make quite a difference I would think?

Reply on news.ycombinator.com