Deploying a Strapi application should be straightforward — clone your repo, install dependencies, build the project, start the server, and you’re good to go. But what happens when you’ve done everything right, and the server still crashes, hangs, or simply gives you a white screen? That’s the frustrating experience I went through recently. Let me walk you through what happened, what I learned, and what you should absolutely check when deploying Strapi — especially if you’re doing it on a free-tier instance.
The Setup
I followed the standard process:
Spun up an EC2 instance
Installed Node.js, npm, and all required dependencies
Cloned my Strapi project
Built and started the app
Everything seemed fine at first. But just when I thought I was done…
The First Sign: The Instance Hung
After finishing the setup and starting the Strapi server, the instance froze. No access via the browser. I couldn’t even ping the IP. When I tried to connect again, it was unresponsive.
First thought? Security Group settings.
I checked all the security group rules — they were open for the required ports (1337 for Strapi, 22 for SSH, etc.). Everything seemed perfect on that end.
I tried re-adding the port for Strapi again, hoping something might reset. Still no progress.
The Hunt for a Cause
I started suspecting a memory issue. It’s not uncommon — Strapi is powerful, but it’s also resource-hungry. So I logged into the instance using SSH (thankfully that still worked) and started trying to free up space.
Deleted unused files
Checked running processes
Killed unnecessary services
But no matter what I did, Strapi still wouldn’t load properly — only a blank white screen in the browser.
The Realization: Free Tier Limitations
That’s when it hit me — I was using an EC2 free-tier instance (t2.micro).
The problem wasn’t my code, or security groups, or even the OS. It was simply that the server didn’t have enough resources (CPU, RAM) to run Strapi effectively. The white screen was the result of the front-end admin panel timing out or not rendering at all due to insufficient power.
The Fix: Upgrade the Instance
To confirm my suspicion, I spun up a new instance — this time a t2.small (still relatively low-cost, but better than free-tier). I repeated the exact same setup process:
Cloned the repo
Installed Node and dependencies
Built the project
Started the server
And it worked! Strapi loaded fine. The admin panel appeared, and I could log in, configure content types, and everything else I needed.
Final Thoughts & What’s Next
While t2.small worked, I noticed some minor sluggishness during production prep. So in my next test, I’ll try running the project on a t2.medium to ensure smooth performance under production load.
Key Takeaways for Anyone Deploying Strapi
Avoid free-tier instances for Strapi, especially
t2.micro. They simply don’t have enough memory or CPU to handle the app, especially once you build it for production.Don’t assume it’s your code — sometimes the environment is the issue.
Start with a small paid instance like
t2.smallort2.mediumfor real-world testing.Monitor resources with tools like
htoportopduring deployment.Always SSH in to verify what’s happening, even if the browser shows a white screen.
Next Up: Testing Strapi on t2.medium
In the next article, I’ll share the results of running the production-ready version of Strapi on a t2.medium instance — including performance benchmarks, memory usage, and tips for optimizing your deployment even further.
Have you faced similar issues deploying Strapi or any other headless CMS? Drop your experience in the comments let’s learn from each other!
Related reads:
External resources: