Cacheiro offers self-hosted remote caching for Nx and Lerna after Nx plugin deprecations

Creating your own Remote Cache Server for Nx and Lerna with Cacheiro

🌐 Este artigo também está disponível em Português. If you work with monorepos using Nx or Lerna, you already know that remote caching is practically a superpower. The ability to run a build, test, or lint in your CI pipeline (or on a colleague's machine) and share that result instantly with the rest of the team saves precious hours of pipeline and processing time. To get this benefit, the default and official solution is Nx Cloud. It is a fantastic service, but it can weigh on the budget of smaller teams or run into strict data security policies at companies that require strict self-hosted solutions. If you have tried to bypass Nx Cloud costs recently, you most likely faced a chaotic scenario. The Rollercoaster of Self-Hosted Caching in Nx The history of hosting your own cache in Nx feels like a soap opera. In the beginning, the community relied on third-party tools. Then, Nx (formerly NRWL) removed free open-source support, centralizing everything into their paid tier. Later, they backtracked and released official, free packages for self-hosting (featuring plugins for File System, AWS S3, Google Cloud Storage, and Azure). And then came the recent cold shower: Nx abruptly deprecated all official self-hosted cache packages due to security concerns (you can check the details in the official Nx deprecation documentation). The remote caching capability still natively exists within the Nx core, but the community was left stranded without official, secure tools to bridge the connection to storage providers. To deeply understand this rollercoaster, Emily Xiong's Medium article does an incredible job of detailing this history of caching solutions. It was precisely while dealing with this pain in my own work that I decided to build a solution to fill this gap. Introducing Cacheiro The Cacheiro project was born to give the community back the freedom to host their own remote cache securely, modernly, and completely for free. And before you ask: yes, the name is a play on words! It joins the technical root Cache with the Portuguese suffix -eiro (which denotes a profession or someone who does a specific job, like a fazendeiro / farmer or pedreiro / bricklayer). "Cacheiro" is the one who takes care of your cache. Unlike other opinionated and rigid alternatives, Cacheiro was designed as a modular library, published in individual packages. You pick and plug only what you actually need. It is: 100% Free and Open Source. Highly extensible: you can easily customize the logic according to your infrastructure needs. Ready for the current ecosystem: It already ships with production-ready plugins for File System (FS) and Amazon S3. Aligned Roadmap: Coming soon, we will release plugins for Google Cloud Storage (GCS) and Azure, covering 100% of the gap left by the deprecated packages. 🔒 Security First: Since the deprecation of the official Nx plugins happened due to security reasons, Cacheiro was built with double the attention to this aspect. The project strictly utilizes the latest versions of its underlying libraries (free of known vulnerabilities), underwent code auditing to mitigate common loopholes, and implements a robust encryption layer resilient against injection or artifact leaks. How to test it in less than 2 minutes (Practical Example) Even though Cacheiro is a library meant for building your custom server, the main repository already comes with a fully working example ready to run locally at 127.0.0.1:3000. If you want to see the magic happen right now on your machine using the File System (FS) plugin, just follow these quick steps: 1. Spin up the example server Clone the repository, install the dependencies at the root, configure the local runner environment, and start the development server: git clone https://github.com/rerodrigues/nx-remote-cache-server.git cd nx-remote-cache-server npm install # Navigate to the runner package and set up the environment cd packages/cacheiro-runner cp config/local.json.example config/local.json # Start the server npm run dev That's it! Your remote cache server is up and running at http://127.0.0.1:3000. 2. Connect your Nx or Lerna project Nx can identify and consume a remote cache directly via native environment variables. For a production or daily development setup, the ideal approach is to save these variables in your terminal configuration file (like .bashrc or .zshrc) or inject them directly into your CI secrets / environment variables (GitHub Actions, GitLab CI, etc.). For our local example, configure it using the default token (change-me): export NX_REMOTE_CACHE_URL="http://127.0.0.1:3000" export NX_REMOTE_CACHE_TOKEN="change-me" With these variables defined in your monorepo's terminal, just run your project's standard commands: # **If you are using Nx:** npx nx run-many -t build # **If you are using Lerna:** npx lerna run build Run the command once to generate and upload the cache to your local server. Run it a second time and witness the performance boost with the cache being served remotely by Cacheiro. Simple as that. What's Next? This is just the first article in a series where we will explore the full potential of Cacheiro. In the upcoming posts, we will go through step-by-step tutorials on how to deploy this to production for real: Part 2: How to build and customize your cache server using the File System (FS) plugin. Part 3: How to deploy Cacheiro to AWS integrating with Amazon S3. If your team is facing this issue today, make sure to check out the official project repository, leave a star, and of course, contribute with feedback or Pull Requests! Access the GitHub Repository: rerodrigues/nx-remote-cache-server How about your team? How do you handle Nx caching today? Are you using Nx Cloud, did you migrate to another alternative, or were you stuck without knowing what to do after the official packages were deprecated? Leave a comment below, share your experience, and let's talk about it! See you in the next post!

4 hours ago

Criando seu próprio Servidor de Cache Remoto para Nx e Lerna com o Cacheiro

🌐 This article is also available in English. Se você trabalha com monorepos usando Nx ou Lerna, sabe que o cache remoto é praticamente um superpoder. A capacidade de rodar um build, teste ou lint no CI (ou na máquina de um colega) e compartilhar esse resultado instantaneamente com o resto do time economiza horas preciosas de pipeline e processamento. Para ter esse benefício, a solução padrão e oficial é o Nx Cloud. É um serviço fantástico, mas que pode pesar no orçamento de times menores ou esbarrar em políticas estritas de segurança de dados de algumas empresas que exigem soluções self-hosted (auto-hospedadas). Se você tentou fugir dos custos do Nx Cloud recentemente, provavelmente se deparou com um cenário caótico. A Montanha-Russa do Cache Self-Hosted no Nx O histórico de quem tenta hospedar o próprio cache no Nx parece uma novela. No início, a comunidade dependia de ferramentas próprias. Depois, a Nx (antiga NRWL) removeu o suporte gratuito open-source, centralizando tudo no plano pago. Mais tarde, voltaram atrás e lançaram pacotes oficiais e gratuitos para self-hosting (com plugins para File System, AWS S3, Google Cloud Storage e Azure). E então veio o balde de água fria recente: a Nx descontinuou abruptamente todos os pacotes oficiais de self-hosted cache devido a problemas de segurança (você pode conferir os detalhes na documentação oficial de depreciação do Nx). A funcionalidade de cache remoto ainda existe nativamente no core do Nx, mas a comunidade ficou órfã de ferramentas oficiais e sequras para fazer a ponte com os storages. Para entender a fundo essa novela, o artigo da Emily Xiong no Medium detalha incrivelmente bem esse histórico das soluções de cache. Foi exatamente passando por essa dor no meu trabalho que decidi criar uma solução para cobrir essa lacuna. Apresentando o Cacheiro O Cacheiro nasceu para devolver à comunidade a liberdade de hospedar seu próprio cache remoto de forma segura, moderna e totalmente gratuita. E antes que você pergunte: sim, o nome é uma brincadeira! É a junção da raiz técnica Cache (em inglês) com o sufixo -eiro (que em português denota uma profissão ou alguém que faz algo, como fazendeiro ou pedreiro). O "Cacheiro" é aquele que cuida do seu cache. Diferente de outras soluções engessadas (opinionated), o Cacheiro foi desenhado como uma biblioteca modular, disponibilizada em pacotes individuais. Você escolhe e acopla apenas o que precisa. Ele é: 100% Livre e Open Source. Altamente extensível: você pode personalizar a lógica conforme a necessidade da sua infraestrutura. Pronto para o ecossistema atual: Já conta com plugins prontos para Sistema de Arquivos (FS) e Amazon S3. Roadmap alinhado: Em breve, teremos os plugins para Google Cloud Storage (GCS) e Azure, cobrindo 100% da lacuna deixada pelos plugins descontinuados. 🔒 Segurança em Primeiro Lugar: Como a descontinuação dos plugins da Nx aconteceu por motivos de segurança, o Cacheiro foi construído com atenção redobrada nesse aspecto. O projeto utiliza estritamente as versões mais recentes de suas bibliotecas base (sem vulnerabilidades conhecidas), passou por auditoria de código para mitigar brechas comuns e implementa uma camada de criptografia robusta e resiliente contra falhas de injeção ou vazamento de artefatos. Como testar em menos de 2 minutos (Exemplo Prático) Embora o Cacheiro seja uma biblioteca para você construir o seu servidor customizado, o repositório principal já vem com um exemplo funcional pronto para rodar localmente no endereço 127.0.0.1:3000. Se você quer ver a mágica acontecer agora mesmo na sua máquina usando o plugin de File System (FS), basta seguir estes passos rápidos: 1. Suba o servidor de exemplo Clone o repositório, instale as dependências na raiz, configure o arquivo local do runner e inicie o servidor de desenvolvimento: git clone https://github.com/rerodrigues/nx-remote-cache-server.git cd nx-remote-cache-server npm install # Navegue até o pacote do runner e configure o ambiente cd packages/cacheiro-runner cp config/local.json.example config/local.json # Inicie o servidor npm run dev Pronto! Seu servidor de cache remoto está rodando no endereço http://127.0.0.1:3000. 2. Conecte o seu projeto Nx ou Lerna O Nx consegue identificar e usar o cache remoto diretamente através de variáveis de ambiente nativas. Para o ambiente de produção ou desenvolvimento diário, o ideal é salvar essas variáveis no arquivo de configuração do seu terminal (como .bashrc ou .zshrc) ou configurá-las diretamente nos Secrets / Environment Variables do seu CI (GitHub Actions, GitLab CI, etc.). Para o nosso exemplo local, configure com o token padrão (change-me): export NX_REMOTE_CACHE_URL="http://127.0.0.1:3000" export NX_REMOTE_CACHE_TOKEN="change-me" Com as variáveis definidas no terminal do seu monorepositório, basta rodar os comandos padrão do seu projeto: # **Se você usa Nx:** npx nx run-many -t build # **Se você usa Lerna:** npx lerna run build Execute o comando uma vez para gerar e enviar o cache para o servidor local. Rode uma segunda vez e veja o ganho de performance com o cache sendo servido remotamente pelo Cacheiro. Simples assim. O que vem a seguir? Este é apenas o primeiro artigo de uma série onde vamos explorar o potencial máximo do Cacheiro. Nos próximos posts, faremos tutoriais passo a passo de como colocar isso em produção de verdade: Parte 2: Como criar e customizar seu servidor de cache usando o plugin de File System (FS). Parte 3: Como subir o Cacheiro na AWS integrando com o Amazon S3. Se você está enfrentando esse problema no seu time hoje, não deixe de conferir o repositório oficial do projeto, deixar sua estrela e, claro, contribuir com feedbacks ou Pull Requests! Acesse o repositório no GitHub: rerodrigues/nx-remote-cache-server E no seu time? Como vocês lidam com o cache do Nx hoje? Usam o Nx Cloud, migraram para outra alternativa ou estavam travados sem saber o que fazer após a descontinuação dos pacotes oficiais? Deixe seu comentário abaixo, conte sua experiência e vamos trocar uma ideia! Nos vemos no próximo post!

4 hours ago