🚨 Pulumi Error: 'error reading from server: EOF' — Cause, Fix, and Troubleshooting Guide

Overview

error: error reading from server: EOF means Pulumi’s CLI was in the middle of talking to a server over gRPC or HTTP and the other side closed the connection unexpectedly (EOF = “end of file”, i.e. the stream ended with no more bytes). It is a transport-layer failure, not a bug in your program logic, and it can surface when talking to Pulumi Cloud (app.pulumi.com), a self-managed state backend (S3, Azure Blob, GCS), or even the local plugin/language-host gRPC channels that Pulumi spins up internally.

Because the error is about a dropped connection, the same message can come from very different places: a flaky network, a proxy that kills long-lived connections, a provider plugin that crashed, or a huge state file that timed out during upload. The message is generic, so diagnosis is about finding which connection died.

error: error reading from server: EOF

Symptoms

• pulumi up, pulumi preview, pulumi refresh, or pulumi destroy fails partway through with error reading from server: EOF.
• The operation sometimes succeeds on a simple retry, pointing to a transient network or backend issue.
• Failures cluster on large stacks (many resources / large state) or during long-running resource creates.
• You are behind a corporate proxy, VPN, or firewall that terminates idle or long-lived connections.
• A provider plugin process crashed (you may also see the plugin exit in verbose logs), and the internal gRPC stream to it returned EOF.

Common Root Causes

1. Transient network drop to Pulumi Cloud or the state backend

The most common cause is simply that the TCP/TLS connection to api.pulumi.com (or your S3/Blob/GCS endpoint) was interrupted — Wi-Fi blip, VPN reconnect, cloud NAT gateway hiccup — while Pulumi was streaming engine events or reading/writing checkpoint state.

error: error reading from server: EOF
    at reading update events for stack dev

2. A proxy, load balancer, or firewall that kills long-lived connections

Corporate proxies and some cloud load balancers cap connection lifetime or idle time. A long pulumi up (large deployment, slow resource) can exceed that limit, and the proxy sends a RST/close that Pulumi reads as EOF. Squid, Zscaler, and misconfigured HTTP_PROXY/HTTPS_PROXY values are frequent culprits.

3. A provider or language plugin crashed mid-operation

Pulumi talks to provider plugins (pulumi-resource-aws, etc.) and the language host (pulumi-language-nodejs) over local gRPC. If one of those subprocesses panics or is OOM-killed, the engine’s read on that stream returns EOF. This often coincides with an out-of-memory condition on a large program.

panic: runtime error: invalid memory address or nil pointer dereference
error: error reading from server: EOF

4. State file too large / backend timeout

Very large stacks produce large checkpoint payloads. Uploading or downloading state to a slow or throttled backend (or hitting an S3/Blob request timeout) can drop the connection before the transfer completes.

5. Outage or throttling on Pulumi Cloud

Rarely, the Pulumi Cloud service itself is degraded or is rate-limiting your organization, closing connections server-side.

How to Diagnose

Start by confirming whether it is reproducible or transient, then turn on verbose logging to see which connection died.

# Retry once — many EOFs are transient network blips.
pulumi up

# Turn on engine + gRPC logging to see the last successful call before EOF.
# -v=9 is very verbose; --logflow follows plugin logs too.
pulumi up --logtostderr -v=9 --logflow 2> pulumi-debug.log

# Confirm which backend you are actually talking to.
pulumi whoami --verbose
pulumi stack --show-urns   # large output here hints at a big state file

# Check whether a proxy is in play (a common EOF source).
env | grep -i proxy
# On the Pulumi Cloud path, verify basic connectivity + TLS.
curl -sS -o /dev/null -w '%{http_code}\n' https://api.pulumi.com/api/user

# If you self-manage state, verify backend reachability, e.g. S3:
aws s3 ls s3://my-pulumi-state-bucket/ --summarize | tail

Fixes

Transient blips — just retry (and enable retry-friendly habits): Most EOFs disappear on a second run. Re-run the exact command; Pulumi’s state is a checkpoint, so it resumes cleanly.

pulumi up

Behind a proxy — set the proxy variables correctly (or bypass for the backend host): Point Pulumi at the right proxy and exclude internal/backend hosts from it.

export HTTPS_PROXY="http://proxy.corp.example:3128"
export NO_PROXY="api.pulumi.com,.amazonaws.com,localhost,127.0.0.1"
pulumi up

If the proxy is the one killing long connections, ask your network team to raise the idle/connection timeout, or run Pulumi from a host that does not go through it (e.g. a CI runner in-cloud).

Plugin crash / OOM — give the host more memory and update plugins: If verbose logs show a plugin panic or the process was OOM-killed, increase available memory and refresh plugins.

# Update all plugins to current, stable versions.
pulumi plugin ls
pulumi plugin install   # reinstalls the versions your project needs

# For large Node.js programs, raise the V8 heap limit for the language host.
export NODE_OPTIONS="--max-old-space-size=4096"
pulumi up

Large state / slow backend — reduce payload and retry: Break enormous stacks into smaller ones (micro-stacks with stack references), and prefer a backend region close to where you run Pulumi. For S3/Blob/GCS, confirm you are not being throttled.

Confirm Pulumi Cloud health: If nothing local explains it, check status.pulumi.com for an ongoing incident before spending more time locally.

What to Watch Out For

• EOF is a symptom, not a root cause — always grab -v=9 --logflow output to see the last call before the disconnect.
• A retry that “fixes” it does not mean the problem is gone; recurring EOFs point to a proxy timeout or an undersized runner.
• Do not confuse this with authentication errors — EOF is a dropped connection, not a 401/403.
• Splitting one giant stack into several is the durable fix for state-size-driven EOFs.
• In CI, ensure the runner has stable egress and enough memory; ephemeral runners with tight limits amplify plugin OOM crashes.

Related Guides

• Pulumi Error: ‘Running program failed with an unhandled exception’ — Troubleshooting Guide
• Pulumi Error: ‘failed to load language plugin nodejs’ — Troubleshooting Guide
• Pulumi Error: ‘update failed’ — Troubleshooting Guide