docker laravel app with astro frontend

Question

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?

alexdo · Answer

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!

Bobby · Answer

Hi there,

I might be wrong, but this behavior is pretty common when doing first-time installs on small Droplets. Composer and Node module installs are very CPU and memory intensive, and on a $4 or even a 2 GB Droplet it’s easy to hit 100% CPU and memory pressure, which can make the Droplet feel unresponsive.

In many cases this can still work with a bit of tuning. Enabling some swap helps a lot, especially during the initial install. It also helps to avoid running composer install and npm install every time the containers start. A common pattern is to build the Docker images locally or in CI, then deploy prebuilt images to the Droplet.

For a small setup, Laravel, MySQL, and a Node based frontend can run fine on a Droplet once everything is built and running, but the build phase needs more resources than people often expect. If you’d rather not deal with that, App Platform handles the build step for you and keeps it isolated from runtime.

So it can work on a Droplet with some adjustments, but moving build work out of runtime and adding a bit of swap usually makes a big difference.

Report this

docker laravel app with astro frontend

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today