By keneucker
I have been developing a laravel (with mysql) + astro frontend application locally on my machine using docker and when it came to start testing it on a server I choose to go with a Digital Ocean Droplet. However, on first test I am seeing the CPU hitting 100% usage for hours and eventually the droplet becomes unusable, while initially I am unable to get back into the console. I went back to the drawing board with how my docker configuration was set up for production and decides to try a more powerful droplet (1 intel vcpu + 2GB RAM) and still the same results.
I feel like laravel (mysql) and astro is not exactly a massive application and I certainly don’t expect the machine to be haulting when trying to run these services for the first time. I will point out that laravel will get installed (+ other composer dependencies) on first run and node modules need to be installed on first run, so that may be a one time additional load, but to halt for hours seems wrong.
Are other people able to run these minor applications on a droplet or am I forced to go App Platform instead?
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Heya, @keneucker
This is usually caused by heavy first-run build work rather than the application size or a broken Droplet.
If your containers are running composer install and npm install on startup, it’s very easy to saturate a small Droplet. Composer dependency resolution, Node module installs, Astro builds, and MySQL initialization are all CPU- and disk-intensive. On 1 vCPU (even with 2 GB RAM), this can peg the CPU at 100% for a long time and make the Droplet appear unreachable, including over SSH.
For production, these steps should not happen at runtime. The usual approach is to build everything ahead of time (locally or in CI) using a multi-stage Dockerfile, then deploy pre-built images to the Droplet. A startup should only involve launching services, not compiling or installing dependencies.
It’s also worth checking memory pressure. Node + Composer + MySQL together can easily push a small Droplet into swapping or OOM behaviour, which makes the system feel “hung.” Adding swap and keeping build steps off the server typically stabilizes things immediately.
You’re not forced to use App Platform — many people run Laravel + frontend stacks on Droplets successfully — but the key is moving builds out of container startup so the Droplet only runs already-built code.
Hope that this helps!
Become a contributor for community
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
DigitalOcean Documentation
Full documentation for every DigitalOcean product.
Resources for startups and SMBs
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
The developer cloud
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Get started for free
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.