Hacker News new | ask | show | jobs
by Rauchg 3729 days ago
CEO of https://zeit.co here! Happy to answer any questions throughout the day :)
13 comments

Any chance of some clarification around the limits of the free tier?

> 20 FREE deploys per month

So I can only run the `now` command 20 times each month? What are you using to track how many times I've run it already? IP? NPM username? Package name?

>1MB size limit per file

Is this at deployment time or is this also enforced at runtime? If I deploy a 900kb sqlite file, then add 200kb of records to it at runtime, what's going to happen?

> Perfect for open-source demos, classrooms, tutorials & testing.

Are 20 deploys per month really enough to use in a teaching context? I'd love to use this tool in the web tech module I teach at my university, but I think most students would burn through 20 deploys in a week, let alone a month. Is there any chance this limit could be re-thought for teaching purposes?

I wouldn't mind if some of the other restrictions were changed, but free tiers that halt development til the start of next month don't sound great for learning to me.

Really cool website! I'm confused though exactly what is going on. Is this kind of like Heroku? What are the pros and cons of this service? For context, I'm currently running a production node/express/mongo service on Digital Ocean.
Compared to other providers, there's absolutely no setup involved. No Procfiles, ports, containers, dynos, processes, instances… Just type `now` where you have a `package.json`.
This is very cool. I'm excited to use this in my next project. I like the zero setup, no fuss, secure by default features. I guess 4 more questions:

1) Does "Dynamic Realtime Scaling" mean you spin up more clusters and do load balancing automatically?

2) Can your $15/month cost cover this? Or is that what the 50GB bandwidth cap is for?

3) The nature of this service means we need to use a DB service like mLab (mongoLab) or run our own DB server right?

4) What about production logs?

Protip: put an extra new line between items or HN eats your line breaks :(
fixed, thx
How is there no port? I have to run my server on some port, are you saying I can choose whatever my port I want and your service detects that somehow? I don't need to use process.env.PORT ?
Cool. But what about persistence / choice of database and how can I scale up / down?
Curious about performance of npm install, seems like it's one thing that could make it not so snappy. For compiled modules, does it have a decent amount of memory/CPU on the instances? How about connectivity? Does it use a mirror for NPM? Might it in the future?
Our biggest focus is `npm install` performance. We have multiple caches to make it the best possible experience for you.

Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.

> Every time you run `now` it's as if you had installed from scratch (including semver invalidations like ^ or ~). The focus is on reproducibility.

This is very confusing to me as these seem to be contradictory statements. Installing "from scratch" (I take this to mean, as if node_modules is an empty folder) is not a reproducible action, as all it takes is one sub-dependency releasing a new version to change your installation.

Can you clarify what you mean and resolve this seeming paradox?

In order for you and your team to never rely on transient local state (either in the cloud or your own computer), we "start from scratch".

However, our process of starting from scratch is actually faster than running `npm install` on your own computer in many cases.

As an example, I've found myself getting into the habit of using `now` instead of `localhost`.

This doesn't address the poster's issue: If you reinstall every time, the results won't always be the same (not that I personally hold this as a big issue, I'd consider it on the programmer to freeze their package.json)
I think it's "reproducible" in the sense that it starts from scratch every time, rather than sometimes starting from scratch, and other times starting with a pre-populated node_modules. If you want actual versioning reproducibility, you'll need to put an npm-shrinkwrap.json in your root.
I see. They shouldn’t use the word “reproducible” then, because something is either reproducible or it’s not.

If they just mean, “We ignore everything but your package.json to generate a deploy,” say that, don’t mis-use the word “reproducible.”

(Heroku, for example, has put a lot of effort into making deploying to their platform actually, truly, really-the-same-years-into-the-future reproducible. `npm install`, especially without shrinkwrap -- and `now` doesn't seem to be using shrinkwrap -- will never get there.)

I’m still not 100% if I get what they are doing or not.

After all, I need some sort of index.js or dist/foo.js in my package, and if they aren’t using git or anything, then isn’t this by definition happening based on transient local state (my local files at `now`-time)?

> `now` doesn't seem to be using shrinkwrap

They aren't? I haven't tried a deployment, but was hoping/assuming they'd upload a shrinkwrap along with everything else and that it would drive the install as per usual.

> I’m still not 100% if I get what they are doing or not.

I think their angle is to lower barriers to entry close to zero for cloud deployments, and thus drain a shallow ocean. "Shallow" in the sense that there are devs who are interested, but maybe not interested enough to buy into terminology like "dynos" or "cartridges" or "lambdas". "Ocean" in the sense that there are (supposedly) quite a few of these people.

So the deploys do not depends on npm infrastructure at all?
Something that’s bothering me is: Is there any way to deploy via `now` with secrets? You know: API keys or the like? `_src` is always public in the free plan and I don’t see any documentation around providing environment variables.
my guess is that for free tier, it's targeted at demo/tutorial so environment variables wouldn't be necessary. If you are serious about privacy then you have to upgrade to paid tier.

But heroku does offer environment variables to free tier and it is handy for database keys and 3rd part API keys, so I guess they will add that at some point through some user-facing web interface or just cli options.

> so env variables would not be necessary

My initial thought as well — but it’s simply not true. Let's say you want to demo something that is using Firebase on the back end. You can't just give away your credentials or your demo may get very broken very quickly… and you’ll foot the bill

A couple questions:

(1) I notice that your pricing chart mentions storage. I'm wondering what that typically would consist of? Only thing I can think of are static assets as I imagine a codebase — even with a million npm module dependencies — wouldn't come close to 1GB let alone 100.

(2) Is it possible to back your apps with a database/datastore? Say I want to use MongoDB with my app. Would I need to purchase a third party service and set the MONGO_URL in the env? Are there any plans to offer database services as add-ons?

A more techy question, how can you let anyone use any port, how will your proxy know where to redirect?
sudo netstat -plnt
Nice, is it meant for permanent hosting or just for prototyping and how does it compare to Cloudnode (https://cloudno.de)
Not received my confirmation email yet, it has been > 10 minutes
Fixed! Sorry about that. We exceeded all quotas. All emails should be going out smoothly :)
Same here. There seem to be problems with the current spike.
I got mine now. It took nearly an hour. Despite that, my early tests ran solid. The apps got hosted on AWS us-west-1.
Excuse my ignorance, but could this work with Meteor?
I'm curious about the differences between hosting a node app on zeit vs heroku.
How do you plan to appeal to the enterprise/larger apps market?
Can this be used with a CI service very easily?
What's the difference with dokku?