CEO of https://zeit.co here!
Happy to answer any questions throughout the day :)
> 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.
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?
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?
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`.
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)?
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.
I haven’t kept my personal site up with no linkrot for the past 10 years by making technology choices on a whim, you know?
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.
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
(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?