Juan Gómez · Automations, Backend & DevOps

Running large language models locally has evolved from a niche experiment to a practical workflow for developers who value privacy, control, and offline capability. In this post, I’ll walk through a production-grade setup of Ollama—paired with model selection strategies based on your hardware constraints—and show how to integrate it seamlessly with Cline, an AI-powered coding assistant.

Why Local LLMs Matter

Before diving into the technical setup, let’s establish why this matters:

The case for running large language models locally has never been stronger. Privacy guarantees (zero data leaving your machine), predictable latency (no network jitter), zero per-token API costs, and offline capability are compelling advantages for any development workflow that touches LLMs.

Apple Silicon’s unified memory architecture makes it uniquely capable for local inference at the consumer and professional level. Unlike discrete GPU setups where VRAM is a hard ceiling, Apple’s unified memory pool is shared between CPU and GPU. A MacBook Pro with 64 GB of unified memory can load models that would require a $20,000+ datacenter GPU to match.

For years, enterprise Drupal shops have faced an uncomfortable trade-off. Installation Profiles – those monolithic *.profile files bundled with custom modules, hard-coded configuration, and installer logic – were the only reliable way to standardize a platform across dozens of sites. They worked, but they ossified. Every division-specific tweak meant a fork. Every fork meant a maintenance burden that grew quadratically with the number of tenants.

Drupal 11 changes this equation. With Recipes stabilized in core as of the 11.x release cycle, we now have a composable alternative that fundamentally shifts how we provision and scale enterprise platforms. This post explores the architectural implications for large-scale multisite ecosystems running dozens of divisions.