DEV Community: Afu Tse (Chainiz)

AWS Graviton: Cómo mejorar el Precio-Rendimiento de tus workloads en AWS

Afu Tse (Chainiz) — Wed, 10 Jun 2026 21:51:10 +0000

Introducción

Reducir costos en la nube suele requerir iniciativas complejas: optimización de recursos, rediseño de arquitecturas, revisión de licencias o implementación de prácticas FinOps.

Sin embargo, existe una optimización que muchas organizaciones pasan por alto: migrar workloads desde instancias x86 tradicionales hacia instancias basadas en AWS Graviton.

AWS Graviton es una familia de procesadores ARM64 diseñados por Amazon para ejecutar cargas de trabajo cloud-native con una mejor relación entre costo, rendimiento y consumo energético.

Este artículo analiza qué es AWS Graviton, cuándo conviene utilizarlo y qué resultados reales han obtenido empresas que ya lo usan en producción.

El Problema: Más Costos Sin Más Valor

Muchas organizaciones ejecutan aplicaciones sobre procesadores Intel o AMD simplemente porque siempre lo han hecho.

Sin embargo, gran parte de las aplicaciones modernas:

APIs REST
Microservicios
Kubernetes
Docker
Node.js
Java
Python
Go
PostgreSQL
Redis

No requieren características específicas de x86.

En estos escenarios, seguir utilizando instancias tradicionales puede significar pagar más por resultados similares.

¿Qué es AWS Graviton?

AWS Graviton es una familia de procesadores ARM desarrollados por Amazon Web Services específicamente para la nube.

A diferencia de los procesadores genéricos utilizados en centros de datos tradicionales, Graviton fue diseñado para las cargas de trabajo más comunes dentro de AWS.

Generación	Año	Características
Graviton	2018	Primera generación
Graviton2	2020	Mejor rendimiento y menor costo
Graviton3	2022	Optimización para cómputo intensivo y Machine Learning
Graviton4	2024	Más núcleos, memoria y rendimiento

Beneficios de AWS Graviton

1. Menor costo operativo

Las instancias Graviton suelen ser más económicas que sus equivalentes x86.

En muchos escenarios los ahorros directos oscilan entre 10% y 25%.

2. Mejor precio-rendimiento

AWS promociona Graviton principalmente por su mejora en precio-rendimiento.

Esto significa obtener más capacidad de procesamiento por cada dólar invertido.

3. Menor consumo energético

Los procesadores ARM se caracterizan por su eficiencia energética.

Esto contribuye a reducir el consumo eléctrico y la huella de carbono de las cargas de trabajo.

4. Compatibilidad con el ecosistema moderno

Graviton funciona de forma nativa con:

Docker
Kubernetes (EKS)
ECS
Lambda
Node.js
Java
Python
Go
.NET
PostgreSQL
MySQL
Redis

Comparativa de Costos

Tomemos una instancia de propósito general con características similares.

Característica	x86 (M7i)	ARM (M7g)
vCPU	2	2
Memoria	8 GB	8 GB
Precio por hora	$0.096 USD	$0.077 USD
Diferencia	—	~20% menos

Cluster Kubernetes

Supongamos un cluster EKS con 20 nodos.

Concepto	x86	Graviton
Costo mensual	$1,402 USD	$1,124 USD
Ahorro mensual	—	$278 USD
Ahorro anual	—	$3,336 USD

Importante: AWS suele hablar de hasta 40% mejor precio-rendimiento, no necesariamente 40% menos costo. El beneficio combina ahorro económico y mayor rendimiento. En muchos casos, la reducción directa de costos se encuentra entre 10% y 25%.

Benchmarks Verificados

Amazon RDS PostgreSQL

AWS ejecutó benchmarks sobre Amazon RDS PostgreSQL comparando Graviton4 con generaciones anteriores. Los resultados mostraron:

Métrica	Graviton4 vs Graviton3	Graviton4 vs Graviton2
Queries por segundo	+23%	+41%
Queries por dólar	+23%	+34%
Latencia	-19%	-29%

Fuente:
https://aws.amazon.com/blogs/database/leveling-up-amazon-rds-with-aws-graviton4-benchmarks/

Casos de Éxito

Salesforce

Migró infraestructura analítica basada en Vertica hacia instancias AWS Graviton.

Resultados obtenidos:

15% reducción de costos
40%+ mejora en consultas
30%+ mejora en dashboards complejos
30% mejora en tasa de éxito de cargas

Fuente: https://aws.amazon.com/solutions/case-studies/salesforce-graviton-case-study/

Supabase

Migró PostgreSQL y APIs desde instancias T3a hacia T4g.

Resultados obtenidos:

28% mejor rendimiento
10% menor costo por instancia

Fuente: https://aws.amazon.com/ec2/graviton/customers/

Ably

Migró la mayoría de sus workloads Java, Go y Ruby.

Resultados obtenidos:

Hasta 40% mejor precio-rendimiento
Migración realizada por un único ingeniero en pocos meses

Fuente: https://aws.amazon.com/ec2/graviton/customers/

Quantcast

Migró su base de datos distribuida Kamke.

Resultados obtenidos:

40% mejor precio-rendimiento

Fuente: https://aws.amazon.com/ec2/graviton/customers/

Sprinklr

Migró microservicios y workloads intensivos de almacenamiento hacia Graviton4.

Resultados obtenidos:

15% mejora de rendimiento en microservicios Java
30% mejora en workloads storage-intensive
20% menos núcleos requeridos

Fuente: https://aws.amazon.com/solutions/case-studies/sprinklr-case-study-graviton/

¿Qué Debo Validar Antes de Migrar?

Compatibilidad ARM64

Verifica que:

Tu aplicación soporte ARM64
Tus dependencias soporten ARM64
Tus imágenes Docker tengan versión ARM64

Docker Multi-Arquitectura

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t my-app:latest .

CI/CD

Asegúrate de que tus pipelines soporten compilación multi-arquitectura.

Benchmarking

Antes de migrar:

Despliega la aplicación en x86.
Despliega la misma aplicación en Graviton.
Ejecuta pruebas de carga.
Compara:

Throughput
Latencia
Uso de CPU
Consumo de memoria
Costo por hora

¿Cuándo Tiene Sentido Migrar?

AWS Graviton suele ser una excelente opción para:

Kubernetes (EKS)
Microservicios
APIs REST
Node.js
Java
Python
Go
PostgreSQL
Redis
Procesamiento de datos

Puede requerir más análisis cuando existen dependencias propietarias o binarios que únicamente soportan x86.

Conclusiones

AWS Graviton ya no es una tecnología emergente.

Empresas como Salesforce, Supabase, Ably, Quantcast y Sprinklr ejecutan workloads críticos sobre Graviton obteniendo mejoras medibles en costos y rendimiento.

Los resultados publicados muestran:

Entre 10% y 25% de ahorro directo en costos.
Hasta 40% mejor precio-rendimiento.
Mejoras significativas en throughput y latencia.
Menor consumo energético.

Para equipos DevOps, Platform Engineering y FinOps, Graviton representa una de las optimizaciones con mejor retorno de inversión disponibles actualmente en AWS.

La mejor forma de evaluar su impacto es sencilla:

Despliega una prueba de concepto, mide los resultados y deja que los números hablen por sí solos.

Referencias

AWS Graviton: https://aws.amazon.com/ec2/graviton/
AWS Graviton Customers: https://aws.amazon.com/ec2/graviton/customers
Salesforce Case Study: https://aws.amazon.com/solutions/case-studies/salesforce-graviton-case-study/
Sprinklr Case Study: https://aws.amazon.com/solutions/case-studies/sprinklr-case-study-graviton/
AWS Pricing Calculator: https://calculator.aws/
Amazon EKS: https://aws.amazon.com/eks/
Docker Multi-Platform Builds: https://docs.docker.com/build/building/multi-platform/
FinOps Foundation: https://www.finops.org/

Nota: Los resultados pueden variar según la carga de trabajo, la región AWS, la arquitectura de la aplicación y el tipo de instancia utilizado. Se recomienda realizar pruebas de rendimiento antes de una migración a producción.

Deploy OpenClaw on AWS Lightsail without manual headaches

Afu Tse (Chainiz) — Tue, 02 Jun 2026 13:43:34 +0000

This article is an English adaptation of the original Spanish post:
Desplegar OpenClaw en AWS Lightsail sin sufrir 😎

If you want to deploy OpenClaw on AWS Lightsail in a simple, repeatable way without fighting through manual steps every time, a great option is to use AWS CDK + Python + uv.

In this tutorial, I’ll show you how to provision the required infrastructure using Infrastructure as Code.

🦀 OpenClaw + AWS Lightsail + IaC

Why automate this?

Doing it manually once is fine.

Doing it manually again and again? Not so fun.

With Infrastructure as Code, you get:

Fewer manual errors
Consistent deployments
Fully repeatable environments
Faster setup for your team
Everything versioned in Git

The goal is not just to create a Lightsail instance. The goal is to have a deployment process that you can reproduce, destroy, improve, and run again whenever needed.

What does this stack create?

This project provisions an OpenClaw environment on AWS Lightsail, including:

An OpenClaw Lightsail instance: openclaw_ls_1_0
Public ports: 22, 80, and 443
A static public Lightsail IP
Optional snapshots
IAM role automation for Amazon Bedrock
Automatic association and disassociation of the static public IP during the stack lifecycle

Quick prerequisites

Before starting, make sure you have the following installed:

Python 3.11+
uv, for Python package and project management
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI

You can install the AWS CDK CLI globally with:

npm i -g aws-cdk

0. Clone the repository

Clone the project repository: aws-cdk-lightsail-openclaw

git clone https://github.com/r3xakead0/aws-cdk-lightsail-openclaw.git
cd aws-cdk-lightsail-openclaw

1. Prepare your local environment

Before synthesizing or deploying the stack, prepare your local environment by installing the project dependencies and validating that your AWS credentials are configured correctly.

Check installed versions

python --version
uv --version
node --version
aws --version
cdk --version

Make sure you have:

Python 3.11+
uv installed
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI

Install project dependencies

From the root of the repository, run:

uv sync

Configure your AWS credentials

If you do not have AWS credentials configured yet, run:

aws configure

You will need to provide:

AWS Access Key ID
AWS Secret Access Key
Default region, for example us-east-1
Default output format, for example json

If you use AWS profiles, export the profile before continuing.

For macOS/Linux:

export AWS_PROFILE=<TU_PROFILE>

For Windows PowerShell:

$env:AWS_PROFILE="<TU_PROFILE>"

Validate AWS access

Run:

aws sts get-caller-identity

You should see an output similar to:

{
  "UserId": "...",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::X234X67X901X:user/your-user"
}

2. Review the configuration file

Open the following file:

config/dev.json

Validate the main fields:

account
region, for example us-east-1
availability_zone, for example us-east-1a
key_pair_name, for example openclaw-dev-key
ssh_cidr
enable_auto_snapshot, which is false by default

This file defines the environment-specific configuration for your deployment.

3. Create or import the Lightsail key pair

This part is important: the key pair must be a Lightsail key pair, not an EC2 key pair.

It also needs to exist in the same region defined in your configuration file.

macOS/Linux

Generate the key:

ssh-keygen -t rsa -b 4096 -m PEM -f ~/.ssh/openclaw-dev-key -C "openclaw-lightsail"
chmod 600 ~/.ssh/openclaw-dev-key
chmod 644 ~/.ssh/openclaw-dev-key.pub

Import it into Lightsail:

aws lightsail import-key-pair \
  --key-pair-name openclaw-dev-key \
  --public-key-base64 "$(cat ~/.ssh/openclaw-dev-key.pub)" \
  --region us-east-1

Validate that the key pair exists:

aws lightsail get-key-pairs \
  --region us-east-1 \
  --query "keyPairs[?name=='openclaw-dev-key'].name" \
  --output table

Windows PowerShell

Generate the key:

ssh-keygen -t rsa -b 4096 -m PEM -f "$HOME\.ssh\openclaw-dev-key" -C "openclaw-lightsail"

Import it into Lightsail:

$pub = Get-Content "$HOME\.ssh\openclaw-dev-key.pub" -Raw
aws lightsail import-key-pair `
  --key-pair-name openclaw-dev-key `
  --public-key-base64 $pub `
  --region us-east-1

Validate it:

aws lightsail get-key-pairs --region us-east-1 --query "keyPairs[?name=='openclaw-dev-key'].name" --output table

4. Bootstrap CDK

You only need to bootstrap once per AWS account and region.

Linux/macOS

./scripts/linux-mac/dev/bootstrap <ACCOUNT_ID> <REGION>

Windows PowerShell

.\scripts\windows\dev\bootstrap.ps1 -AccountId <ACCOUNT_ID> -Region <REGION>

5. Run synth and diff

Before deploying, it is a good idea to synthesize the CloudFormation template and review the changes.

Linux/macOS

./scripts/linux-mac/dev/synth
./scripts/linux-mac/dev/diff

Windows PowerShell

.\scripts\windows\dev\synth.ps1
.\scripts\windows\dev\diff.ps1

The diff step helps you review what CDK is going to create, update, or remove before applying the deployment.

6. Deploy

Now deploy the stack.

Linux/macOS

./scripts/linux-mac/dev/deploy

Windows PowerShell

.\scripts\windows\dev\deploy.ps1

When the deployment finishes, you should see outputs such as:

InstanceName
StaticIpName
PublicIp
BedrockRoleArn

7. Verify that everything is running

Connect to the instance using SSH.

Linux/macOS

ssh -i ~/.ssh/openclaw-dev-key ubuntu@<PUBLIC_IP>

Windows PowerShell

ssh -i "$HOME\.ssh\openclaw-dev-key" ubuntu@<PUBLIC_IP>

Then run a quick check:

Open http://<PUBLIC_IP> in your browser
Verify the instance in the Lightsail console
Confirm that the Bedrock IAM role exists

At this point, your OpenClaw deployment should be up and running on AWS Lightsail.

8. Destroy the stack when you are done

If this is just a test environment, do not forget to destroy the resources when you finish to avoid unnecessary costs.

Linux/macOS

./scripts/linux-mac/dev/destroy

Windows PowerShell

.\scripts\windows\dev\destroy.ps1

Troubleshooting

`The KeyPair does not exist`

This usually means one of the following:

The key pair was not created or imported into Lightsail
The key pair exists in another region
The key pair is an EC2 key pair instead of a Lightsail key pair

To fix it, create or import the key pair in Lightsail and make sure it is in the correct AWS region.

Stack stuck in `ROLLBACK_COMPLETE`

If the stack failed and ended in ROLLBACK_COMPLETE, delete the failed stack and deploy again.

CDK Node.js warning

If CDK shows a warning related to Node.js, make sure you are using Node.js 22 LTS.

If you use nvm, run:

nvm use

Final thoughts

The main idea behind this project is not only to deploy an instance.

The real value is having a repeatable deployment process that does not depend on lost notes, forgotten manual steps, or one-time console configurations.

With AWS CDK, Python, uv, and Lightsail, you can keep the setup simple while still applying Infrastructure as Code practices from the beginning.

This makes the deployment easier to reproduce, easier to destroy, and easier to improve over time.

Desplegar OpenClaw en AWS Lightsail sin sufrir 😎

Afu Tse (Chainiz) — Fri, 24 Apr 2026 15:09:45 +0000

Si deseas desplegar OpenClaw en AWS Lightsail de manera simple, sencilla, repetible y sin pelear con pasos manuales, una buena opción es usar AWS CDK + Python + uv.

En este tutorial te muestro cómo levantar toda la infraestructura con Infrastructure as Code.

🦀 OpenClaw + AWS Lightsail + IaC

¿Por qué automatizar esto?

Porque hacerlo a mano una vez está bien, pero repetirlo muchas veces es "pesado".

Con IaC (Infrastructure as Code) ganas:

Menos errores humanos
Despliegues consistentes
Repetibilidad total (crear y destruir cuando quieras)
Más velocidad para tu equipo
Todo versionado en Git

¿Que crea este stack o proyecto?

Tu infraestructura en Lightsail con:

Instancia OpenClaw (openclaw_ls_1_0)
Puertos públicos 22, 80, 443
IP estática pública de Lightsail
Snapshots opcionales
Automatización de rol IAM para Bedrock
Asociación/desasociación automática de la IP estática pública durante el ciclo de vida del stack

Pre requisitos rápidos

Necesitas tener instalado:

Python 3.11+
uv (Gestor de paquetes y proyectos)
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI (npm i -g aws-cdk)

0) Clona el repositorio

Clonar el repositorio de github del proyecto aws-cdk-lightsail-openclaw

git clone https://github.com/r3xakead0/aws-cdk-lightsail-openclaw.git
cd aws-cdk-lightsail-openclaw

1) Prepara el entorno local

Antes de sintetizar o desplegar el stack, prepara tu entorno local instalando las dependencias del proyecto y validando que tus credenciales de AWS estén configuradas correctamente.

Verifica las versiones instaladas

python --version
uv --version
node --version
aws --version
cdk --version

Asegúrate de tener:

Python 3.11+
uv instalado
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI

Instala las dependencias del proyecto

Desde la raíz del repositorio, ejecuta:

uv sync

Configura tus credenciales de AWS

Si todavía no tienes credenciales configuradas, ejecuta:

aws configure

Ingresa tu:

AWS Access Key ID
AWS Secret Access Key
Default region, por ejemplo us-east-1
Default output format, por ejemplo json

Si usas perfiles de AWS, puedes exportar el perfil antes de continuar:

macOS/Linux

export AWS_PROFILE=<TU_PROFILE>

Windows PowerShell

$env:AWS_PROFILE="<TU_PROFILE>"

Valida el acceso a AWS

aws sts get-caller-identity

Deberías ver una salida similar a:

{
  "UserId": "...",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/your-user"
}

2) Revisa el archivo de configuración

Archivo: config/dev.json

Asegúrate de validar estos campos:

account
región (ej. us-east-1)
availability_zone (ej. us-east-1a)
key_pair_name (ej. openclaw-dev-key)
ssh_cidr
enable_auto_snapshot (false por defecto)

3) Crea/importa el key pair en Lightsail

Importante: tiene que ser de Lightsail (no EC2) y en la misma region especificada en el archivo de configuración.

macOS/Linux

Genera la clave:

ssh-keygen -t rsa -b 4096 -m PEM -f ~/.ssh/openclaw-dev-key -C "openclaw-lightsail"
chmod 600 ~/.ssh/openclaw-dev-key
chmod 644 ~/.ssh/openclaw-dev-key.pub

Impórtala:

aws lightsail import-key-pair \
  --key-pair-name openclaw-dev-key \
  --public-key-base64 "$(cat ~/.ssh/openclaw-dev-key.pub)" \
  --region us-east-1

Valídala:

aws lightsail get-key-pairs \
  --region us-east-1 \
  --query "keyPairs[?name=='openclaw-dev-key'].name" \
  --output table

Windows PowerShell

Genera la clave:

ssh-keygen -t rsa -b 4096 -m PEM -f "$HOME\.ssh\openclaw-dev-key" -C "openclaw-lightsail"

Impórtala:

$pub = Get-Content "$HOME\.ssh\openclaw-dev-key.pub" -Raw
aws lightsail import-key-pair `
  --key-pair-name openclaw-dev-key `
  --public-key-base64 $pub `
  --region us-east-1

Valídala:

aws lightsail get-key-pairs --region us-east-1 --query "keyPairs[?name=='openclaw-dev-key'].name" --output table

4) Bootstrap (solo una vez por cuenta/region)

Linux/macOS

./scripts/linux-mac/dev/bootstrap <ACCOUNT_ID> <REGION>

Windows PowerShell

.\scripts\windows\dev\bootstrap.ps1 -AccountId <ACCOUNT_ID> -Region <REGION>

5) Synth + Diff (para revisar antes de desplegar)

Linux/macOS

./scripts/linux-mac/dev/synth
./scripts/linux-mac/dev/diff

Windows PowerShell

.\scripts\windows\dev\synth.ps1
.\scripts\windows\dev\diff.ps1

6) Deploy

Linux/macOS

./scripts/linux-mac/dev/deploy

Windows PowerShell

.\scripts\windows\dev\deploy.ps1

Cuando termine, verás outputs como:

InstanceName
StaticIpName
PublicIp
BedrockRoleArn

7) Verifica que todo este vivo

Conéctate por SSH:

Linux/macOS

ssh -i ~/.ssh/openclaw-dev-key ubuntu@<PUBLIC_IP>

Windows PowerShell

ssh -i "$HOME\.ssh\openclaw-dev-key" ubuntu@<PUBLIC_IP>

Chequeo rápido:

abre http://<PUBLIC_IP>
revisa la instancia en consola de Lightsail
confirma que el rol de Bedrock existe en IAM

8) Destroy cuando termines (para no gastar de mas)

Linux/macOS

./scripts/linux-mac/dev/destroy

Windows PowerShell

.\scripts\windows\dev\destroy.ps1

Solución de problemas

`The KeyPair does not exist`

El key pair no esta en Lightsail, esta en otra region o es de EC2.
Solución: crealo/importalo en Lightsail y en la region correcta.

Stack en `ROLLBACK_COMPLETE`

Borra el stack fallido y vuelve a desplegar.

Warning de Node en CDK

Ejecuta nvm use para usar Node 22 LTS.

Conclusión

La idea no es solo desplegar una instancia, sino dejar el proceso listo para repetirse sin depender de pasos manuales ni configuraciones perdidas.

Instalación de JFrog Artifactory OSS en Ubuntu 22.04 (Jammy) + PostgreSQL - Guia Completa

Afu Tse (Chainiz) — Fri, 06 Feb 2026 13:58:22 +0000

Tutorial paso a paso para instalar JFrog Artifactory OSS en Ubuntu 22.04 (Jammy) usando PostgreSQL.

⚠️ Nota: Este setup no está pensado para producción. Cambia contraseñas, restringe accesos y revisa backups/SSL antes de usarlo en entornos reales.

Contenido

Requisitos
Arquitectura
0. Preparación de Ubuntu 22.04 (Jammy)
1. Base de datos PostgreSQL
2. Instalar Artifactory OSS
3. Configurar Artifactory OSS para usar PostgreSQL
4. Iniciar Artifactory
5. Abrir puertos (firewall)
6. Entrar a la UI y credenciales por defecto
Comandos útiles
Referencias

Requisitos

VM con Ubuntu 22.04 (Jammy)
Acceso sudo (superusuario)
Conectividad a internet para bajar paquetes
Puertos abiertos en firewall (al menos 8082)

Arquitectura

0. Preparación de Ubuntu 22.04 (Jammy)

Confirmar que estás en Jammy:

lsb_release -a

cat /etc/os-release

Actualizar librerías:

sudo apt update && sudo apt -y upgrade

1. Base de datos PostgreSQL

1.1 Instalar PostgreSQL

sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

1.2 Crear la base de datos y usuario para Artifactory

sudo -u postgres psql <<'SQL'
CREATE USER artifactory WITH PASSWORD 'ArtifactoryDemo123!';
CREATE DATABASE artifactory OWNER artifactory ENCODING 'UTF8';
GRANT ALL PRIVILEGES ON DATABASE artifactory TO artifactory;
SQL

⚠️ Recomendación: cambia esta contraseña si la VM no es 100% privada.

2. Instalar Artifactory OSS

2.1 Agregar repositorio + key

Agregar el repo OSS (para Jammy):

echo "deb https://releases.jfrog.io/artifactory/artifactory-debs jammy main" | sudo tee -a /etc/apt/sources.list

Agregar la key GPG:

wget -qO - https://releases.jfrog.io/artifactory/api/gpg/key/public | sudo apt-key add -

2.2 Instalar Artifactory OSS (Open Source)

JFrog recomienda tener net-tools como prerequisito:

sudo apt-get update
sudo apt-get install -y net-tools
sudo apt-get install -y jfrog-artifactory-oss

3. Configurar Artifactory OSS para usar PostgreSQL

La configuración principal está en:

JFROG_HOME por defecto: /opt/jfrog
Archivo: /opt/jfrog/artifactory/var/etc/system.yaml

3.1 Detener Artifactory

sudo systemctl stop artifactory

3.2 Editar `system.yaml`

Abrir el archivo system.yaml con editor VIM:

sudo vim /opt/jfrog/artifactory/var/etc/system.yaml

Agregar/ajustar esta sección shared:

shared:
  database:
    type: postgresql
    driver: org.postgresql.Driver
    url: jdbc:postgresql://127.0.0.1:5432/artifactory
    username: artifactory
    password: ArtifactoryDemo123!

4. Iniciar Artifactory

sudo systemctl start artifactory.service
sudo systemctl status artifactory.service --no-pager

Ver logs si hace falta:

sudo journalctl -u artifactory -n 200 --no-pager

5. Abrir puertos (firewall)

Para la UI normalmente se usa 8082 (y a veces 8081 según el setup). Para este caso, abre al menos 8082.

sudo ufw allow 8082/tcp
sudo ufw status

6. Entrar a la UI y credenciales por defecto

Abrir:

http://<TU_IP>:8082/
http://<TU_IP>:8082/ui/
Login directo: http://<TU_IP>:8082/ui/login

Credenciales por defecto:

admin / password

⚠️ Cambia la contraseña apenas puedas.

Fix rápido (OSS): deshabilitar jfconnect (workaround login “stuck”)

Si al iniciar sesión el botón queda inactivo o se “queda pegado” el login (reportado en OSS 7.125.x), aplica este workaround:

Edita:

sudo vim /opt/jfrog/artifactory/var/etc/system.yaml

Agrega esto a nivel raíz (top-level), NO dentro de shared:

jfconnect:
  enabled: false

Reinicia:

sudo systemctl restart artifactory

Prueba de nuevo: http://:8082/ui/ o http://:8082/ui/login

Comandos útiles

Estado del servicio:

sudo systemctl status artifactory --no-pager

Logs recientes:

sudo journalctl -u artifactory -n 200 --no-pager

Reiniciar:

sudo systemctl restart artifactory

Verifica que el puertos está escuchando y en qué interfaz:

sudo ss -lntp | egrep ':8081|:8082'
curl -I http://127.0.0.1:8082/ | head
curl -I http://127.0.0.1:8081/ | head

Referencias

JFrog Platform Installation Documentation: https://jfrog.com/help/r/jfrog-platform-installation-documentation
Install Artifactory on Debian/Ubuntu (APT): https://jfrog.com/help/r/jfrog-installation-setup-documentation/install-artifactory-on-debian
PostgreSQL Documentation: https://www.postgresql.org/docs/

Implementar un sitio web estático en Cloudflare Pages usando Terraform y Wrangler CLI

Afu Tse (Chainiz) — Sun, 25 Jan 2026 22:58:01 +0000

En este tutorial, aprenderá a implementar un sitio web estático en Cloudflare Pages usando Terraform para el aprovisionamiento de infraestructura y Wrangler CLI para la implementación manual.

Este enfoque le permite administrar su proyecto de Cloudflare Pages como Infraestructura como Código (IaC), manteniendo un proceso de implementación simple y flexible.

Qué aprenderás

Al finalizar este tutorial, podrás:

Aprovisionar un proyecto de Cloudflare Pages con Terraform
Implementar un sitio web estático con la CLI de Wrangler
Configurar un dominio personalizado (opcional)
Administrar tu infraestructura de forma limpia y reproducible
Destruir todos los recursos de forma segura cuando ya no sean necesarios

¿Por qué Cloudflare Pages + Terraform?

Cloudflare Pages ofrece una plataforma rápida, global y sin servidor para alojar sitios web estáticos.

Terraform te permite definir y versionar tu infraestructura, lo que garantiza la consistencia y repetibilidad de tus implementaciones.

La combinación de ambas herramientas te ofrece:

Infraestructura como Código
CDN global rápida
Implementación sencilla de sitios estáticos
Gestión sencilla de dominios
Separación clara entre infraestructura y aplicación

Requisitos Previos

Antes de comenzar, asegúrese de tener:

Terraform instalado (versión 1.10.0 o superior)
Cuenta de Cloudflare con acceso a Pages
API Token de Cloudflare con permisos de Cloudflare Pages
Node.js y npm instalados (para Wrangler CLI)

Estructura del Proyecto

cloudflare-tf-staticweb/
└── infrastructure/           # Carpeta con archivos terraform
    ├── main.tf               # Configuración de Terraform
    ├── providers.tf          # Configuración de providers
    ├── variables.tf          # Definición de variables
    ├── cloudflare.tf         # Recursos de Cloudflare Pages
    ├── outputs.tf            # Outputs del proyecto
    ├── terraform.tfvars      # Variables (no versionar)
└── website/                  # Carpeta con el sitio web estático
    └── index.html            # Contiene el HTLM de la página principal
    └── styles.css            # Contiene el CSS de la página principal
    └── script.js             # Contiene el JS de la página principal

Variables

Variable	Descripción	Requerida	Default
`cloudflare_api_token`	API Token de Cloudflare	Sí	-
`cloudflare_account_id`	Account ID de Cloudflare	Sí	-
`project_name`	Nombre del proyecto	No	"my-website"
`custom_domain`	Dominio personalizado	No	""

Configuración Inicial

1. Crear el Proyecto

# Crear la estructura de carpetas
mkdir cloudflare-tf-staticweb
cd cloudflare-tf-staticweb

2. Configurar la Infraestructura

En la carpeta "cloudflare-tf-staticweb"

# Crear la carpeta de la infraestructura
mkdir infrastructure

# Accede a la carpeta infraestructura
cd infrastructure

# Crear el archivo "main.tf"
cat <<EOF > main.tf
terraform {
  required_version = ">= 1.10.0"

  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}
EOF

# Crear el archivo "provider.tf"
cat <<EOF > provider.tf
provider "cloudflare" {
  api_token = var.cloudflare_api_token
}
EOF

# Crear el archivo "variables.tf"
cat <<EOF > variables.tf
variable "cloudflare_api_token" {
  description = "The API token for Cloudflare account"
  type        = string
  sensitive   = true
}

variable "cloudflare_account_id" {
  description = "Cloudflare Account ID (visible on dashboard)"
  type        = string
}

variable "project_name" {
  description = "Project name in Cloudflare Pages"
  type        = string
  default     = "my-website"
}

variable "custom_domain" {
  description = "Custom domain (optional, leave blank if not used)"
  type        = string
  default     = ""
}
EOF

# Crear el archivo "outputs.tf"
cat <<EOF > outputs.tf
output "pages_project_url" {
  description = "Full URL of the Cloudflare Pages project"
  value       = "https://${cloudflare_pages_project.website.subdomain}"
}

output "pages_project_subdomain" {
  description = "Subdomain assigned by Cloudflare Pages"
  value       = cloudflare_pages_project.website.subdomain
}

output "project_id" {
  description = "Cloudflare project ID"
  value       = cloudflare_pages_project.website.id
}

output "project_name" {
  description = "Project Name"
  value       = cloudflare_pages_project.website.name
}

output "custom_domain_url" {
  description = "Custom domain URL (if configured)"
  value       = var.custom_domain != "" ? "https://${var.custom_domain}" : "Not configured"
}
EOF

# Crear el archivo "cloudflare.tf"
cat <<EOF > cloudflare.tf
resource "cloudflare_pages_project" "website" {
  account_id        = var.cloudflare_account_id
  name              = var.project_name
  production_branch = "main"

  build_config {
    build_command   = ""        # No build required for static HTML
    destination_dir = "website" # Folder containing index.html
    root_dir        = ""        # Repository root
  }

  # Environment variables (if needed in the future)
  deployment_configs {
    production {
      environment_variables = {
        ENVIRONMENT = "production"
      }
    }

    preview {
      environment_variables = {
        ENVIRONMENT = "preview"
      }
    }
  }

}

# Custom domain (optional)
resource "cloudflare_pages_domain" "custom_domain" {
  count        = var.custom_domain != "" ? 1 : 0
  account_id   = var.cloudflare_account_id
  project_name = cloudflare_pages_project.website.name
  domain       = var.custom_domain
}
EOF

3. Configurar la pagina web

En la carpeta "cloudflare-tf-staticweb"

# Crear la carpeta del sitio web
mkdir website

# Accede a la del sitio web
cd website

# Crear el archivo "index.html"
cat > index.html << 'EOF'
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Simple Web App</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <div class="container">
        <h1 id="greeting">Hello, World!</h1>
        <input type="text" id="nameInput" placeholder="Enter your name">
        <button id="updateBtn">Update Greeting</button>
    </div>
    <script src="script.js"></script>
</body>
</html>
EOF

# Crear el archivo "styles.css"
cat > styles.css << 'EOF'
* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

body {
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
    background: linear-gradient(135deg, #6a11cb 0%, #2575fc 100%);
    min-height: 100vh;
    display: flex;
    justify-content: center;
    align-items: center;
}

.container {
    background: white;
    padding: 2rem;
    border-radius: 10px;
    box-shadow: 0 10px 30px rgba(0, 0, 0, 0.2);
    text-align: center;
    max-width: 400px;
    width: 90%;
}

h1 {
    color: #333;
    margin-bottom: 1.5rem;
    font-size: 2rem;
}

input {
    padding: 0.8rem;
    width: 100%;
    margin-bottom: 1rem;
    border: 2px solid #ddd;
    border-radius: 5px;
    font-size: 1rem;
}

input:focus {
    outline: none;
    border-color: #2575fc;
}

button {
    background: #2575fc;
    color: white;
    border: none;
    padding: 0.8rem 1.5rem;
    border-radius: 5px;
    cursor: pointer;
    font-size: 1rem;
    transition: background 0.3s;
}

button:hover {
    background: #1a68e8;
}
EOF

# Crear el archivo "script.js"
cat > script.js << 'EOF'
// Get DOM elements
const greetingElement = document.getElementById('greeting');
const nameInput = document.getElementById('nameInput');
const updateButton = document.getElementById('updateBtn');

// Update greeting when button is clicked
updateButton.addEventListener('click', () => {
    const name = nameInput.value.trim();

    if (name) {
        greetingElement.textContent = `Hello, ${name}!`;
        nameInput.value = ''; // Clear input
    } else {
        greetingElement.textContent = 'Please enter your name!';
        setTimeout(() => {
            greetingElement.textContent = 'Hello, World!';
        }, 2000);
    }
});

// Also update on Enter key press
nameInput.addEventListener('keypress', (e) => {
    if (e.key === 'Enter') {
        updateButton.click();
    }
});
EOF

4. Obtener tu Account ID en Cloudflare

Ve al Cloudflare Dashboard → Account Home
Click en los 3 puntos la lado del "Account Name"
Click en "Copy account ID"

5. Crear API Token en Cloudflare

Ve a Cloudflare Dashboard → Manage Account → Account API Tokens
Click en "Create Token" → "Create Custom Token"

Configura los permisos necesarios:

Token name: Terraform Cloudflare Pages

Permissions:
├── Account
│   ├── Cloudflare Pages → Edit
│   └── Account Settings → Read
└── Zone (opcional, solo si usas dominio personalizado)
    └── DNS → Edit

Zone Resources:
└── Include → All zones from an account → Your_Account

Click en "Continue to summary" → "Create Token"
Copia el token inmediatamente (solo se muestra una vez)

6. Actualizar Configuración

Crear el archivos de variables y asignar los valores

cloudflare_account_id obtenido del paso 4
cloudflare_api_token obtenido del paso 5

# Crear el archivo "terraform.tfvars"
cat <<EOF > terraform.tfvars
# Cloudflare Account ID
cloudflare_account_id = "your-account-id-here"


# Cloudflare API Token
cloudflare_api_token = "your-token"

# Project name
project_name = "my-website"

# Custom domain (optional, leave blank if not used)
custom_domain = ""
EOF

Uso

Crear la Infraestructura con Terraform

Accede a la carpeta infraestructura

cd infrastructure

Inicializar Terraform

terraform init

Validar la configuración

terraform validate
terraform fmt

Planificar cambios

terraform plan

Aplicar cambios

terraform apply -auto-approve

Esto creará el proyecto de Cloudflare Pages, pero aún no habrá contenido desplegado.

Ver outputs

terraform output

Desplegar el Sitio Web con Wrangler

Una vez que Terraform haya creado el proyecto, despliega tu sitio:

1. Instalar Wrangler (solo la primera vez)

npm install -g wrangler

2. Autenticar con Cloudflare

wrangler login

Esto abrirá un navegador para que autorices Wrangler.

3. Desplegar el sitio

Desde la raíz del proyecto

wrangler pages deploy website --project-name=my-website

Reemplaza my-website con el valor de tu variable project_name.

4. Verificar el despliegue

Visita la URL mostrada en el output de Terraform o en el resultado del comando deploy:

terraform output pages_project_url

pages_project_url = "https://my-website-xxx.pages.dev"

Despliegues Futuros

Para actualizar tu sitio después de hacer cambios:

Edita tus archivos en website/
Despliega de nuevo

wrangler pages deploy website --project-name=my-website

Reemplaza my-website con el valor de tu variable project_name.

Dominio Personalizado

Para agregar un dominio personalizado:

Actualiza terraform.tfvars:
```
custom_domain = "www.tudominio.com"
```
Asegúrate de que el dominio esté en Cloudflare
Aplica los cambios
```
terraform apply
```

Destruir Recursos

terraform destroy -auto-approve

Recursos Adicionales

Valkey vs Redis – Explicación simple y practica

Afu Tse (Chainiz) — Thu, 08 Jan 2026 21:59:36 +0000

🔑 ¿Qué es Valkey?

Valkey es un fork open-source de Redis, creado en 2024, totalmente compatible, creado tras el cambio de licencia de Redis para mantener una alternativa 100% open source y respaldado por la Linux Foundation.

Surge como respuesta al cambio de licencia de Redis (Redis ≥ 7.4), que dejó de ser open source bajo los estándares de la OSI.

👉 Objetivo de Valkey

Mantener un Redis 100% open source
Compatibilidad total con Redis (comandos, protocolo, clientes)
Gobernanza comunitaria y neutral
Sin vendor lock-in

En la práctica:

Valkey es Redis, pero con licencia abierta y desarrollo comunitario.

🧠 ¿Para qué sirve Valkey?

Exactamente los mismos casos de uso que Redis:

Cache in-memory
Session store
Pub/Sub
Rate limiting
Distributed locks
Streams
Leaderboards
Replication
Persistence (RDB / AOF)
Redis Cluster

⚖️ Valkey vs Redis (comparación rápida)

Característica	Valkey	Redis (≥ 7.4)
Licencia	✅ Open Source (BSD/Apache-style)	❌ RSAL / SSPL
Gobernanza	Linux Foundation	Redis Inc
Compatibilidad	100% Redis	Nativa
Uso comercial	✅ Libre	⚠️ Restricciones
Vendor lock-in	❌ Bajo	⚠️ Mayor
Cloud friendly	✅ Sí	⚠️ Limitado
Soporte K8s	✅ Excelente	✅

🧾 La licencia: el punto clave

Redis hoy

Licencia RSAL / SSPL
No considerada open source por la OSI
Restricciones para SaaS y cloud providers

Valkey

Open source real
Uso comercial sin restricciones
Ideal para empresas, educación y gobiernos

Por eso AWS, Google, Oracle y otros proveedores apoyan Valkey.

🧪 Demo 1 – Valkey local con Docker

docker run -d --name valkey -p 6379:6379 valkey/valkey:latest

Prueba rápida:

redis-cli ping
# PONG

redis-cli set demo "hola valkey"
redis-cli get demo

🧪 Demo 2 – Pub/Sub

Terminal A:

redis-cli subscribe events

Terminal B:

redis-cli publish events "mensaje desde valkey"

Terminal A:

☸️ Demo 3 – Valkey en Kubernetes

Crear el archivo "valkey.yaml"

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: Service
metadata:
  name: valkey
  namespace: demo
  labels:
    app: valkey
spec:
  # Headless Service required by StatefulSet
  clusterIP: None
  selector:
    app: valkey
  ports:
    - name: redis
      port: 6379
      targetPort: 6379
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: valkey
  namespace: demo
spec:
  serviceName: valkey
  replicas: 1
  selector:
    matchLabels:
      app: valkey
  template:
    metadata:
      labels:
        app: valkey
    spec:
      containers:
        - name: valkey
          image: valkey/valkey:latest
          ports:
            - name: redis
              containerPort: 6379
          volumeMounts:
            - name: data
              mountPath: /data
          readinessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 15
            periodSeconds: 10
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

Desplegar:

kubectl apply -f valkey.yaml

Acceso desde un pod:

kubectl run -it --rm vcli -n demo --image=redis:7 -- bash

Ejecuta el ping para validar conexion

redis-cli -h valkey.demo.svc.cluster.local ping
PONG

Código fuente : k8s-valkey-demo

🔄 ¿Tengo que cambiar código si vengo de Redis?

👉 No.

Mismos comandos
Mismo protocolo RESP
Mismos clientes (redis-cli, node-redis, ioredis, etc.)

Solo cambia la imagen:

image: valkey/valkey

🚀 Conclusión

Si estás construyendo:

Kubernetes
SaaS
Plataformas cloud
Proyectos open source

👉 Valkey es la opción recomendada hoy.

Develop Kubernetes Services Locally (Yes, Really) with Telepresence

Afu Tse (Chainiz) — Wed, 07 Jan 2026 19:19:26 +0000

🚀 What is Telepresence?

Telepresenceis a development tool that lets you connect your local machine directly to a Kubernetes cluster — as if your app were running inside the cluster, even though it’s actually running on your laptop.

🔥 Build, run, and debug Kubernetes services locally, without rebuilding Docker images or redeploying on every change.

🧩 What do developers use Telepresence for?

Telepresence shines in day-to-day Kubernetes development:

✅ Local development against a real cluster
• Your application runs locally
• But it consumes real cluster resources:
• Services
• ConfigMaps
• Secrets
• Internal APIs

No mocks. No fakes. Just real infrastructure.

✅ Intercepting Service traffic
• Telepresence can intercept traffic destined for a Kubernetes Service
• That traffic is transparently redirected to your local app

From the cluster’s point of view, nothing changes.

✅ Fast, comfortable debugging
• Use local logs
• Attach debuggers (VS Code, IntelliJ, etc.)
• Hot reload
• Breakpoints

🙌 All without modifying or risking remote or production environments.

😖 The problem Telepresence solves

❌ Traditional Kubernetes workflow

Every tiny change usually means:

Modify code
docker build
docker push
kubectl apply
Wait for rollout
Test
Repeat 😵‍💫

That’s minutes per iteration — and it kills productivity.

✅ With Telepresence

The workflow becomes:

Change code locally
Save
Test instantly

⏱️ Feedback in seconds, not minutes.

⚙️ How does Telepresence work?

High-level flow:
• Connects to your Kubernetes cluster
• Deploys a Traffic Manager (proxy)
• Intercepts traffic for a Service
• Forwards that traffic to your local machine

From Kubernetes’ perspective:

👉 Your app still exists in the cluster — it just happens to live on your local machine.

🧪 Simple example

Without Telepresence

echo Service → Pod in Kubernetes

With Telepresence

echo Service → your laptop (localhost:9000)

Everything else stays the same:
• Databases
• Other microservices
• Secrets

🔗 Source code: github

🌟 Why you should care

• ⚡ Much faster development cycles
• 🧪 Real debugging against real infrastructure
• 🛡️ Lower risk (no touching prod clusters)
• 🧩 Perfect fit for Kubernetes & microservices

If you work with Kubernetes daily, Telepresence can seriously change how fast — and how comfortably — you build software.

🔗 References

Ejecuta tus servicios de Kubernetes desde tu local con Telepresence

Afu Tse (Chainiz) — Wed, 07 Jan 2026 18:51:56 +0000

¿Qué es Telepresence?

Telepresence es una herramienta de desarrollo que te permite conectar tu computadora local a un clúster de Kubernetes como si tu aplicación local estuviera corriendo dentro del cluster.

En pocas palabras:
🔥 Te deja desarrollar y depurar servicios de Kubernetes sin construir imágenes Docker ni hacer deploy cada vez.

¿Para qué se usa Telepresence?

Se usa principalmente para:

✅ Desarrollo local contra Kubernetes real

Tu app corre localmente
Pero consume Services, ConfigMaps, Secrets y APIs reales del cluster

✅ Interceptar tráfico de un Service

Redirige el tráfico que iba a un Service del cluster
Hacia tu aplicación local

✅ Debugging rápido

Puedes usar logs locales
Debuggers (VS Code, IntelliJ)
Hot reload
Breakpoints

🙌 Todo sin tocar el cluster remoto y/o productivo.

¿Por qué Telepresence es de gran ayuda?

Porque soluciona dolores reales del desarrollo con Kubernetes.

❌ Sin Telepresence (El problema tradicional)

Cada cambio implica:

Cambiar código
docker build
docker push
kubectl apply
Esperar el rollout
Probar
Repetir 😵‍💫

Esto puede tomar minutos por cambio.

✅ Con Telepresence

El flujo se vuelve:

Cambias código local
Guardas
Pruebas inmediatamente

⏱️ Cambios en segundos, no minutos.

¿Cómo funciona Telepresence?

Flujo:

Se conecta al cluster
Inserta un proxy (Traffic Manager)
Intercepta el tráfico de un Service
Lo envía a tu máquina

Desde Kubernetes:
👉 Parece que tu app sigue ahí, pero en realidad está en tu computadora.

Ejemplo

Sin Telepresence:

echo Service → Pod en Kubernetes

Con Telepresence:

echo Service → tu laptop (localhost:9000)

Y el resto del cluster se mantiene igual

Databases
Otros microservicios
Secrets

🔗 Codigo fuente: minikube-telepresence-demo

Beneficios

Desarrollo muchísimo más rápido
Debug real contra infraestructura real
Menor riesgo (no tocas ambientes remotos y/o productivos)
Ideal para Kubernetes + microservicios

Ejecuta Qwen3 + Ollama + Open WebUI en Docker: Tu propio AI Chat local 🧠

Afu Tse (Chainiz) — Fri, 02 Jan 2026 22:15:41 +0000

¿Quieres montar tu propio entorno de IA local con un modelo potente sin pagar por la nube?

Con el repositorio qwen3-container puedes hacerlo fácilmente usando Docker Compose, Ollama y Open WebUI 👇

🔗 código fuente

🔥 En este post te explico qué es, cómo funciona y por qué es útil este proyecto.

🧠 ¿Qué es Qwen3?

Qwen3 es la última generación de modelos de lenguaje grande (LLM) de Alibaba Cloud — disponible en múltiples tamaños y con capacidades impresionantes de generación de texto, razonamiento y tareas complejas.

🧰 ¿Qué hace este repositorio?

El proyecto qwen3-container ofrece un stack listo para producción local que combina:

🧠 Ollama — runtime local para LLMs, con Qwen3 precargado
🌐 Open WebUI — interfaz web tipo chat para interactuar con el modelo
🐳 Docker + Docker Compose — para levantar todo con un solo comando

Esto te permite tener un chat local basado en Qwen3 sin depender de APIs externas ni costos por tokens.

🛠️ ¿Cómo funciona el stack?

El proyecto define dos servicios principales:

📌 ollama-qwen3
Ejecuta el modelo Qwen3 dentro de Ollama y expone una API REST en localhost:11434.
📌 open-webui
Proporciona una interfaz de chat en localhost:3000 desde el navegador, donde puedes conversar con Qwen3 sin programar nada.

📦 Instalación rápida

Clona el repositorio

git clone https://github.com/r3xakead0/qwen3-container.git
cd qwen3-container

Configura tu .env (puedes basarte en .env.example)

# Genera un secreto seguro
openssl rand -hex 32

Levanta los contenedores

docker compose up -d

Acceder
- 📡 API: http://localhost:11434
- 🧠 UI chat: http://localhost:3000

💡 ¿Por qué usar esto?

✅ Privacidad y control: tus datos nunca salen de tu máquina
✅ Sin dependencia de la nube: ni tokens ni facturación
✅ Desarrollo rápido: ideal para prototipos, PoCs o herramientas internas
✅ Personalización: puedes enchufar el API de Ollama a tus propias apps

Este stack es ideal si estás trabajando con soluciones de IA local o quieres explorar modelos open-weight como Qwen3 sin pagar por servicios externos.

🔗 Articulo de referencia

🧩 Recomendaciones

👉 Cambia el valor de WEBUI_SECRET_KEY por un secreto largo y seguro.
👉 Una vez inicializado, deshabilita el registro de nuevos usuarios para proteger tu instancia.

🐧 Comandos de procesamiento de texto en Linux: guía práctica

Afu Tse (Chainiz) — Mon, 29 Dec 2025 05:00:00 +0000

Este post explica de forma didáctica y con ejemplos reales los comandos más usados para procesamiento de texto en Linux:

grep
awk
sed
sort
uniq

Ideal para logs, DevOps, SysAdmin y entrevistas técnicas.

1️⃣ grep – Buscar texto

Buscar errores en un log

grep "ERROR" app.log

Buscar sin distinguir mayúsculas

grep -i "error" app.log

Contar coincidencias

grep -c "ERROR" app.log

Mostrar número de línea

grep -n "Exception" app.log

2️⃣ awk – Trabajar con columnas

Mostrar primera columna

awk '{print $1}' archivo.txt

Ver usuarios conectados

who | awk '{print $1}'

Logs Nginx: IP y URL con error 404

awk '$9 == 404 {print $1, $7}' access.log

Sumar valores (ej. tráfico total)

awk '{sum += $10} END {print sum}' access.log

3️⃣ sed – Editar texto

Reemplazar texto

sed 's/http/https/' archivo.txt

Reemplazo global

sed 's/http/https/g' archivo.txt

Eliminar líneas vacías

sed '/^$/d' archivo.txt

Cambiar configuración directamente

sed -i 's/DEBUG=false/DEBUG=true/' app.conf

4️⃣ sort – Ordenar datos

Ordenar alfabéticamente

sort usuarios.txt

Ordenar números

sort -n numeros.txt

Ordenar por columna

sort -k 2 archivo.txt

Ordenar tamaños reales

ls -lh | sort -k 5 -h

5️⃣ uniq – Eliminar duplicados

⚠️ uniq funciona correctamente solo si los datos están ordenados.

Eliminar duplicados

sort nombres.txt | uniq

Contar repeticiones

sort nombres.txt | uniq -c

Mostrar solo duplicados

sort nombres.txt | uniq -d

🔥 Casos reales combinados

IPs que más requests hacen

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

URLs con más errores 404

awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -nr

Errores más frecuentes

grep "ERROR" app.log | awk '{print $5}' | sort | uniq -c | sort -nr

🧠 Resumen rápido

Comando	Uso principal
grep	Buscar texto
awk	Procesar columnas
sed	Editar texto
sort	Ordenar
uniq	Quitar duplicados

📌 Tip DevOps: estos comandos son fundamentales para analizar logs de Docker, Kubernetes, Nginx, AWS, GCP y Azure.

¡Guárdalo, practícalo y úsalo en entrevistas! 🚀

Reemplacé Docker por Podman para ejecutar LLMs locales (Ollama + DeepSeek)

Afu Tse (Chainiz) — Sun, 28 Dec 2025 17:31:53 +0000

Durante mucho tiempo, mis experimentos locales con IA siguieron el camino habitual:

"Docker, docker-compose, descargar un modelo, levantar una UI y listo."

Pero en algún punto empecé a querer algo más limpio:

Contenedores rootless (sin raíz)
Mejor alineación con Linux de nivel enterprise
Sin depender de un daemon de Docker corriendo en segundo plano

Ahí fue cuando decidí reconstruir mi stack local de LLMs usando Podman.

Este post documenta el resultado:

"Ollama + Open WebUI + DeepSeek R1 ejecutándose localmente con Podman Compose"

¿Por qué Podman?

Si trabajas en cloud o platform engineering, seguramente ya viste esta tendencia:

Podman no usa daemon
Corre rootless por defecto
Se integra muy bien con systemd
Cada vez es más estándar en distribuciones Linux enterprise

Para mí, el objetivo era simple:
ejecutar LLMs locales de la misma forma en que ejecutaría servicios en producción.

El stack

Esto es lo que terminé usando:

Ollama → runtime y API de modelos
Open WebUI → interfaz tipo chat
DeepSeek R1 (1.5B) → liviano pero sorprendentemente capaz
Podman Compose → orquestación
Volúmenes de Podman → persistencia de datos

Todos los contenedores corren dentro de un solo Podman Pod, lo que significa: una red compartida, comunicación por localhost y cero magia rara de DNS.

Arquitectura

El archivo Compose

El corazón de este setup es el podman-compose.yml:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama-deepseek
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
    volumes:
      - ollama-data:/root/.ollama:Z
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "ollama", "list"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  open-webui:
    image: ghcr.io/open-webui/open-webui:latest
    container_name: open-webui
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY:-secret-key-change-me-in-production}
      - ENABLE_SIGNUP=${ENABLE_SIGNUP:-true}
    volumes:
      - open-webui-data:/app/backend/data:Z
    restart: unless-stopped

  model-loader:
    image: ollama/ollama:latest
    container_name: model-loader
    depends_on:
      - ollama
    environment:
      - OLLAMA_HOST=http://ollama:11434
    entrypoint: ["ollama"]
    command: ["pull", "deepseek-r1:1.5b"]
    restart: on-failure

volumes:
  ollama-data:
    driver: local
  open-webui-data:
    driver: local

Codigo fuente

Un detalle pequeño pero importante:
no uso sh -c para el model loader, ya que la imagen de ollama no garantiza un shell, así que llamo al binario directamente.

Ejecución

podman compose up -d

Primer acceso:

Abres http://localhost:3000
Creas el usuario admin inicial (comportamiento esperado)
Empiezas a chatear

Puedes validar Ollama directamente:

curl http://localhost:11434

Qué me gusta de este setup

Después de usarlo un tiempo, hay varias cosas que destacan:

No hay daemon de Docker corriendo
Todo funciona en modo rootless
Separación clara entre runtime, UI y datos
Fácil de convertir en servicios systemd más adelante (Quadlet)

Y lo más importante:
"Esto se siente como infraestructura, no como un demo".

Notas de seguridad (Importante)

Si vas a exponer esto más allá de localhost:

Cambia WEBUI_SECRET_KEY
Desactiva registros públicos después de crear el primer usuario
Considera un reverse proxy

Que sea local no significa que deba ser inseguro.

Conclusión

Ejecutar LLMs localmente no tiene por qué ser desordenado.
Con Podman + Ollama obtienes un setup que se siente:

Limpio
Reproducible
cercano a producción

Si ya usas Podman en tus workloads, este stack encaja perfecto.

Running DeepSeek R1 + Ollama + Open WebUI with Podman Compose

Afu Tse (Chainiz) — Sun, 28 Dec 2025 17:07:16 +0000

If you want to run local LLMs with a clean, containerized setup without Docker, this guide shows how to deploy DeepSeek R1 + Ollama + Open WebUI using Podman Compose.

This setup is ideal for:

Local AI experimentation
Developers who prefer rootless containers
Teams standardizing on Podman instead of Docker

Why use Podman?

Using Podman is recommended because it is more secure and better aligned with Kubernetes: it runs containers rootless by default, does not rely on a daemon, reduces the attack surface, and fits better in enterprise and CI/CD environments. In addition, it is Docker-compatible at the command level, officially supported by Red Hat, and ideal for Linux servers and production, especially when security and compliance are a priority.

Architecture Overview

The stack runs inside a single Podman Pod, meaning all containers share the same network namespace.

Ollama → model runtime & API
Open WebUI → chat-style web interface
Model Loader → one-shot container to pull the model
Volumes → persistent storage for models and app data

Requirements

Podman
Podman Compose (podman compose or podman-compose)
Free ports:
- 11434 (Ollama API)
- 3000 (Open WebUI)

On SELinux-enabled systems, volumes are mounted using :Z to avoid permission issues.

podman-compose.yml

Here is the core compose file powering the stack:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama-deepseek
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_HOST=0.0.0.0:11434
    volumes:
      - ollama-data:/root/.ollama:Z
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "ollama", "list"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

  open-webui:
    image: ghcr.io/open-webui/open-webui:latest
    container_name: open-webui
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY:-secret-key-change-me-in-production}
      - ENABLE_SIGNUP=${ENABLE_SIGNUP:-true}
    volumes:
      - open-webui-data:/app/backend/data:Z
    restart: unless-stopped

  model-loader:
    image: ollama/ollama:latest
    container_name: model-loader
    depends_on:
      - ollama
    environment:
      - OLLAMA_HOST=http://ollama:11434
    entrypoint: ["ollama"]
    command: ["pull", "deepseek-r1:1.5b"]
    restart: on-failure

volumes:
  ollama-data:
    driver: local
  open-webui-data:
    driver: local

source code

Configuration

Create a .env file:

WEBUI_SECRET_KEY=change-me-to-a-long-random-secret
ENABLE_SIGNUP=true

Generate a secure secret:

openssl rand -hex 32

Run the Stack

podman compose -f podman-compose.yml up -d

Check status:

podman ps
podman compose -f podman-compose.yml ps

Access:

Open WebUI → http://localhost:3000
Ollama API → http://localhost:11434

On first access, Open WebUI will prompt you to create the initial admin user (expected behavior).

Validation

Verify Ollama:

curl http://localhost:11434

Expected output:

Ollama is running

List models:

curl http://localhost:11434/api/tags

If the model is missing, pull it manually:

podman exec -it ollama-deepseek ollama pull deepseek-r1:1.5b

Stop & Teardown

Stop containers:

podman compose stop

Remove containers (keep data):

podman compose stop

Full cleanup (⚠️ deletes models and users):

podman compose down -v

Security Notes

Always change WEBUI_SECRET_KEY
After creating the first admin user, disable public signups:

ENABLE_SIGNUP=false

Then recreate:

podman compose up -d --force-recreate

Final Thoughts

Running LLMs locally doesn’t have to be messy.
With Podman + Ollama, you get a setup that feels:

clean
reproducible
and production-adjacent

If you’re already using Podman for your workloads, this stack fits right

DEV Community: Afu Tse (Chainiz)

AWS Graviton: Cómo mejorar el Precio-Rendimiento de tus workloads en AWS

Introducción

El Problema: Más Costos Sin Más Valor

¿Qué es AWS Graviton?

Beneficios de AWS Graviton

1. Menor costo operativo

2. Mejor precio-rendimiento

3. Menor consumo energético

4. Compatibilidad con el ecosistema moderno

Comparativa de Costos

Cluster Kubernetes

Benchmarks Verificados

Amazon RDS PostgreSQL

Casos de Éxito

Salesforce

Supabase

Ably

Quantcast

Sprinklr

¿Qué Debo Validar Antes de Migrar?

Compatibilidad ARM64

Docker Multi-Arquitectura

CI/CD

Benchmarking

¿Cuándo Tiene Sentido Migrar?

Conclusiones

Referencias

Deploy OpenClaw on AWS Lightsail without manual headaches

Why automate this?

What does this stack create?

Quick prerequisites

0. Clone the repository

1. Prepare your local environment

Check installed versions

Install project dependencies

Configure your AWS credentials

Validate AWS access

2. Review the configuration file

3. Create or import the Lightsail key pair

macOS/Linux

Windows PowerShell

4. Bootstrap CDK

Linux/macOS

Windows PowerShell

5. Run synth and diff

Linux/macOS

Windows PowerShell

6. Deploy

Linux/macOS

Windows PowerShell

7. Verify that everything is running

Linux/macOS

Windows PowerShell

8. Destroy the stack when you are done

Linux/macOS

Windows PowerShell

Troubleshooting

The KeyPair does not exist

Stack stuck in ROLLBACK_COMPLETE

CDK Node.js warning

Final thoughts

Desplegar OpenClaw en AWS Lightsail sin sufrir 😎

¿Por qué automatizar esto?

¿Que crea este stack o proyecto?

Pre requisitos rápidos

0) Clona el repositorio

1) Prepara el entorno local

Verifica las versiones instaladas

Instala las dependencias del proyecto

Configura tus credenciales de AWS

Valida el acceso a AWS

2) Revisa el archivo de configuración

3) Crea/importa el key pair en Lightsail

macOS/Linux

Windows PowerShell

4) Bootstrap (solo una vez por cuenta/region)

Linux/macOS

Windows PowerShell

5) Synth + Diff (para revisar antes de desplegar)

`The KeyPair does not exist`

Stack stuck in `ROLLBACK_COMPLETE`

`The KeyPair does not exist`

Stack en `ROLLBACK_COMPLETE`

3.2 Editar `system.yaml`