A Raspberry Pi can be a useful development server, but it still has to share its CPU, memory and storage between everything you ask it to run. A database, PHP workers, file watchers, a browser and a build can each be reasonable on their own and unpleasant together.
I aim for a machine that stays responsive while a realistic development task runs. That is a more useful target than chasing a benchmark score with all the normal services stopped.
Check cooling and power before tuning software
On a supported Raspberry Pi setup with the firmware utilities available, start with:
vcgencmd measure_temp
vcgencmd get_throttledThe throttling result is a bitmask, not a simple yes-or-no temperature reading. Raspberry Pi documents separate flags for current conditions and conditions that have occurred. Interpret the result against that table: a historical flag does not prove that the machine is throttling now.
Watch the readings during a representative build, not just when the machine is idle. If power or thermal limits appear, check the supply, cooling and airflow appropriate to your model before increasing clocks. A configuration tweak cannot make an inadequate power arrangement reliable.
Find where the active files really live
Check the storage layout rather than assuming the system is using the drive you intended:
lsblk -o NAME,TYPE,TRAN,SIZE,FSTYPE,MOUNTPOINTS
df -h
df -iProjects, dependency trees, database files and build output generate different access patterns. If storage appears to be the constraint, compare a representative task before and after any planned move. An SSD or NVMe setup is not automatically the answer to CPU-bound work or a slow remote service.
Before moving a database or boot filesystem, make a recoverable backup and follow the supported migration process for that software. Confirm the final mount and permissions after reboot. A quick file copy is not sufficient evidence that a running database was transferred consistently.
Budget memory across the whole development stack
Use free -h and interval samples from vmstat 1 10 while the normal tools are open. Look at available memory and active swapping alongside responsiveness. The amount of memory labelled free does not tell the whole story.
Compressed swap can be useful, but zram still consumes RAM and processing time. Inspect swapon --show and zramctl to understand what is enabled. Do not copy another machine’s allocation or swappiness value as a universal performance recipe.
Leave room for the operating system, database and interactive tools when choosing worker counts. A machine that completes a build slightly sooner but makes the editor and local site unusable throughout it may be a worse development setup.
Reduce unnecessary parallel work
Check which projects have active watchers, development servers and scheduled tasks. Stop the ones you do not need through their normal controls. Avoid killing unfamiliar processes simply because they appear near the top of a memory list.
Limit build or test concurrency using the tool’s documented option, then compare the whole job’s elapsed time. More processes can increase memory and storage contention without finishing sooner. Keep long imports and image regeneration away from the busiest interactive work where practical.
Pay attention to repeated failures too. A watcher rebuilding continuously or a job retrying without delay can waste more resources than a sensible worker-limit adjustment will save.
Keep local speed separate from deployment compatibility
A fast local server does not prove that a release works on its target host. Check the PHP or runtime version, extensions and application settings used by that environment. A local command-line test also does not establish that the web process uses the same configuration.
Keep a short record of each useful adjustment and how to reverse it. Test the ordinary workflow again after reboot: editor, local page, database task and a representative build. The goal is dependable everyday development, with enough evidence to understand the next slowdown.
Further reading: Raspberry Pi firmware utilities and throttling flags.