Aptly: Creando nuestro propio repositorio

jogofus
22 oct
5 Min. de lectura

El lunes pasado, 20 de octubre de 2025, medio Internet quedó paralizado, en silencio.

Servicios que no funcionaban, páginas web que no respondían, empresas que literalmente no podían trabajar.

¿El motivo? AWS estuvo caído durante toda la mañana, con servicios afectados todavía por la tarde. Aquí dejo la noticia

El problema es que muchas empresas no estaban preparadas para algo así.

Si le preguntas a alguien sobre el cloud, básicamente sus respuestas se centran en que siempre está disponible o que incluso es más seguro.

Pero, ¿es esto cierto?

Es una verdad a medias.

Lo que si es cierto es que las grandes empresas como AWS, Google, Microsoft con Azure, o empresas como Cloudflare (se están viviendo paradas de servicio por los bloqueos de LaLiga en España) disponen de más recursos, tanto económicos, como humanos, como de hardware. Esto supone que pueden invertir mayor cantidad de estos recursos a asegurar hasta cierto nivel la continuidad del servicio.

Pero como siempre decimos la gente que nos dedicamos a esto, el cloud (la nube para los hispanoparlantes) no es más que el ordenador de otro.

¿Qué significa esto?

Que igual que nuestro ordenador de casa puede fallar, el cloud también.

Si bien, como he dicho, hay más recursos destinados a que eso no pase en el cloud, el error humano sigue existiendo. Y todos sabemos que la cadena es tan fuerte como su eslabón más débil.

Y sí, en este caso, el eslabón más débil es el factor humano.

Las personas somos falibles, y en cualquier momento eso puede suponer un problema.

La mentira del cloud: mi humilde opinión

He visto muchas empresas en las que solo trabajan con cloud alegando que es mucho más seguro y que siempre está disponible.

Pero como todos sabemos, dato mata a relato.

Con solo poner un par de ejemplos, como el incendio de OVH de hace un tiempo, los bloqueos de Cloudflare y la reciente caída de AWS, las bases sobre las que se cimentaban ese pensamiento empiezan a tambalearse.

Pero es que, además, si lo complementas con las correspondientes preguntas, puedes hacer que un departamento IT tenga que replantear casi de forma íntegra su infraestructura.

-Si por lo que sea os quedáis sin Internet, ¿podéis seguir trabajando?

-¿Sabes realmente dónde están tus datos/ficheros, si están seguros o si son accesibles por los propietarios del cloud?

No todo es tan bonito como nos lo pintaron.

Yo soy un fiel defensor de tenerlo todo autohospedado en la medida que sea posible.

¿Por qué?

Porque así tengo el control total y absoluto de mis datos y de cómo funciona. Y en la gran mayoría de casos no es necesario que esos servicios estén expuestos a internet.

¿Significa esto que reniego totalmente del cloud? No, por supuesto. Significa que considero que hay que planificar bien la infraestructura según las necesidades.

Actualiza tus servidores en tu red local

Las lineas anteriores han servido para reflejar un poco la situación de dependencia de internet y del cloud en muchísimas ocasiones.

En lo personal, siempre he sido una persona que no confía en que un software que me sea de mucha utilidad siga estando disponible en un futuro cercano, por lo que me gusta guardar distintas versiones. Ya sabéis, por si acaso.

Lo que hacía antes era descargar los paquetes que suelo usar en mi día a día y tenerlos a buen recaudo, pero siempre quise tener mi propio repositorio local de paquetes para poder instalar o actualizar sin depender de internet y, además, poder tener distintas versiones de los paquetes, garantizando así disponer de todos los paquetes aunque estos sean eliminados de los repositorios oficiales o acceder a versiones antiguas que no tengan bugs.

Antiguamente se utilizaba el paquete reprepo para crear tu propio repositorio de paquetes en Linux, pero tenías que crear una estructura de carpetas concreta que, para mí, era bastante tedioso.

Pero apareció aptly, un software que te permite clonar un repositorio entero en local, hacer snapshots del mismo y publicar tanto el repositorio como los snapshots.

Aptly: Repositorios de forma fácil y sencilla

Para empezar a utilizar esta herramienta podemos descargarla desde su página web o directamente desde los repositorios.

apt install aptly

La verdad es que utilizarla es muy fácil e intuitivo, y siguiendo su documentación te haces con ella en unos minutos.

Aquí me gustaría dar un consejo: para este servicio creo conveniente tener un disco secundario donde almacenar los paquetes, ya que ocupan mucho y se puede llenar enseguida.

Para cambiar la ubicación de los paquetes, se encuentra un fichero en ~/.aptly.conf o /etc/aptly.conf , en el que deberemos cambiar una línea.

Dependiendo de la versión de aptly que tengas, es posible que sea un json o un fichero de texto plano.

En el primer caso, siguiendo la documentación oficial, se deberá cambiar la línea de "rootDir": y poner la ubicación que queramos.

Si, como yo, tienes un fichero en texto plano, deberemos cambiar la línea root_dir: tal y como se muestra en la captura.

En primer lugar deberemos crear una clave con gnupg:

gpg --gen-key

Ahora, deberemos exportar e importar en nuestro equipo las claves de los repositorios que vayamos a usar, que en mi caso es debian.

gpg --no-default-keyring --keyring /usr/share/keyrings/debian-archive-keyring.gpg --export | gpg --no-default-keyring --keyring trustedkeys.gpg --import

Para evitar problemas, yo creo una carpeta tmp en la misma carpeta de los repositorios, para no llenar la carpeta local /tmp, ya que generalmente no tendremos tanto espacio (si descargamos main contrib non-free y non-free-firmware llegaremos a 500gb).

mount --bind /mnt/REPOS/tmp /tmp

Una vez hecho esto, montaremos el disco secundario y crearemos la carpeta donde vamos a almacenar los paquetes.

mount /dev/vdb1 /mnt/REPOS

Creamos nuestro propio mirror:

aptly mirror create -architectures=amd64 trixie http://deb.debian.org/debian/ trixie main non-free-firmware

Y procedemos a crear un mirror del oficial:

aptly mirror update trixie

Esto puede llevar un rato porque ocupa bastante. En mi caso se ha descargado 114gb.

Ahora vamos a hacer un snapshot y publicarlo para que sea accesible:

aptly snapshot create trixie-main-2025-10 from mirror trixie
aptly publish snapshot trixie-main-2025-10

Una vez hecho esto ya tenemos descargados y publicados el repositorio, pero no son accesibles ya que no hay ningún servicio exponiendo esta ruta.

Para ello es necesario un servidor web, como nginx o apache, pero la gente de aptly ya han pensado en ello y ofrecen un servidor web ligero integrado con aptly.

La diferencia es que con nginx o apache siempre estará publicado y con aptly tienes que ejecutarlo cada vez que quieras acceder a ellos. Esa ya es decisión de cada uno.

En mi caso, como no necesito que esté público constantemente, voy a hacer uso de aptly: