Spectrum is now read-only. Learn more about the decision in our official announcement.


Our mission is to make cloud computing as easy and accessible as mobile computing. You can find our Next.js community here.


clarify future support of docker on now platform

November 8, 2018 at 6:21pm
The ZEIT community has a new home. This thread is preserved for historical purposes. The content of this conversation may be innaccurrate or out of date. Go to new community home →

clarify future support of docker on now platform

November 8, 2018 at 6:21pm
It seems zeit is moving away from allowing customers to utilize Docker as a common 'primitive'; would you kindly clarify this?
Show previous messages

November 11, 2018 at 5:41am
Even if they are discontinuing Docker, they should find a way to let us host it in a legacy mode... or are there not enough docker users on this platform for them to continue their docker hosting feature?
I get that the new way might be better and more optimised but I have a bunch of Docker images from clients and our previous work that will not be recoded to work with the new Lambda model...
I think they are letting us host Docker it in the legacy mode 🤔
Until they shut it down...
- What do you recommend for all of us in the GraphQL community? You mention that this use case is 'going to be supported', but some clarification of your intents/thoughts would be great! I imagine there are quite a lot of node-based GraphQL servers hosted on Zeit Now v1/Serverless Docker, and as far as I know, GraphQL doesn't play that nicely with the Lambda approach, seeing as the whole idea is to only have one route/endpoint.
Sure, we can host it using now/node, but I'm not sure the cold boot times is all that great in that case.
This is what I was hoping for before the Now-Docker dream was crushed... Can you imagine how cool it would be to write now in your shell, and have both your Dockerfile and docker-compose.yml file be deployed, interpreted in production, exactly as they are in dev and testing modes? This would be a true development-testing-production environment parity.
I believe you definitely shouldn't now (pun intended?...). I deploy my rails apps on Heroku, with or without Dockerizing them. If you haven't tried them for rails, I encourage you to do so. They were the first "is it really that simple??" jaw dropping moment for me. The second was Zeit Now before all that 2.0 mess...
To 's point about cold boot times, I would be curious how, e.g., an expressjs app might perform compared to its Dockerized equivalent. If I could maintain my application's current response times without having to adopt the serverless model (beyond using `/node-server` and also have a solution for websockets), it would ease the burden of adopting v2 before reaching the unknown v1 deprecation date, without a major application rewrite.
While I respect Zeit's decision to pivot into Functions as a service, I think they deserve some fair criticism on how the announcement was made. Enterprises (big and small) rely on cloud services to run their business, we expect clear, frequent and transparent communication about changes, outages and new features. Enterprises have to manage all sort of risks when choosing a cloud provider, since it can have critical impact on how well the business operates.
Many came to Zeit's now for first-class support of Docker, "the" universal standard for containers. It means that some enterprise were starting to rely on it (or planning to) to run their apps to serve their customers.
In my view, abruptly announcing the deprecation of Dockerfile on now, which is a core feature of the service, is simply NOT a way to run a cloud business or any type of business for that matter. And, again in all due respect to Zeit, I found the official responses in this thread were borderline condescending. If we chose dockerfile over functions/lamdas when we decided to use now, there was probably a reason behind the move. Maybe we weren't ready for it, maybe we didn't have the manpower/budget to transition now. So saying that functions/lambdas are better than dockerized application is like saying that apple slices are better than oranges.
Yes serverless is awesome, and I believe that Now 2.0 will have great success in this area but there was great value in native dockerfile support. Again, I want to reiterate that I respect the move and the reasoning.
Thanks again
To people that are looking for alternatives, I have moved my docker setup (docker compose with nginx + NodeJS app) over to Azure Pipelines + Web Apps, together with Cloudflare CDN.
The Azure Pipeline assistant auto-detected my Docker setup, proposed sensible defaults. Bottom line is the Docker DX experience was great. It took me maybe 4 hours in total (being unfamiliar with Azure) to set it up.

November 12, 2018 at 4:52am
we are working on a set of recommendations for GraphQL apps
It's very important to emphasize that no one needs to re-write their apps overnight. You don't have to upgrade to 2.0 tomorrow. We are adding examples, documentation and more features/tools to make the transition painless.
I'm 100% convinced that once you see us getting deeper into our vision with 2.0, you won't miss writing servers at all.
The key to this discussion is that it's not so much "Docker vs Lambdas". It's a lot more nuanced. It's "processes vs threads", "state vs stateless", "non-deterministic scalability vs 1:1 scalability"…
- That sounds great, any idea of an ETA? It would be great if you could touch on the setup of Apollo Engine in this new environment as well. As far as I know, it's based on a binary which won't be usable on Lambdas. If this is correct, I'm assuming it would require a separate deployment somewhere that does support Docker, leading to a single point of failure with no horizontal scalability.
On another note - what about the deployment size limitations on lambda? Our app, which is a medium to large sized GQL node app, was around 67 MB when deployed to now. This was using an alpine based multistage Dockerfile, with absolutely no more fat to trim without starting to remove dependencies. Ironically, the aws-sdk which we use to upload files to S3 itself is about 20mb of that. As far as I understand, this effectively means that this app won't be suitable for Now 2.0 without some serious refactoring to fit the FaaS paradigm - is that correct?
aws-sdk don't need to be bundled when using aws lambdas (it's always available as an import in a lambda), so I guess it might fit 🙂
- Maybe, but only just. But I just remembered, that image size is including the alpine node runtime, which won't be needed here.
I just inspected my app size after yarn tsc and yarn i --production --ignore-optional , and the app size is around 4MB and dependencies 158 MB unzipped - so if one can specify a build script that allows for the trimming of devDependencies (which I assume), then we should be good - at least for now, and in this regard.
And a note on the pricing - as far as I can tell, Now's pricing is exactly double of AWS's pricing - and that's not even including the first free million invocations that comes with vanilla AWS. What should justify paying you twice the fee compared to using some other AWS wrapper, say Apex Up? You do have a nice CLI and domain services, but I guess it'll be up to each developer/company to decide if it's worth paying double the fee for
You're comparing the price of raw lambda to now 2.0, it's not really fair because raw aws lambda can't be called via http without API Gateway
api gateway is $3.5 for 1 million calls
so if you have 1 million lambda executing for 100 ms :
- now v2 : $3.4 (execution) + $0.4 (invocations) = $3.8
- aws : $1.7 (execution) + $3.5 (invocations) = $5.2
it's a simplified use case, but at least it's comparable 🙂
Good point, Luc - haven't used Lambdas before, so I didn't know that :-)

November 12, 2018 at 4:18pm
I've been using Serverless Docker since the announcement of the beta in August. It worked so well, I moved all of my production stuff there. From what I read here, all of that is going away? I really don't know where you guys are going with this. I just moved all my stuff to Zeit, don't make me regret this. :-)
This is how Now described itself prior to V2, and what I think most of user liked about it.
My question is: Did the users that liked v1 asked for such transition to serverless? It's like a totally different product for different usecases
Zeit will eventually drop support for Docker. Unless you are able to re-write your dockerized apps to use the serverless/lambda paradigm, you will want to start looking elsewhere to host those apps. (Please correct me if I'm wrong, Zeit team )
Show more messages