Python y Flask: guía práctica para crear y desplegar tu primera app

Resumen del Artículo ocultar

1 Qué es Flask

2 Requisitos previos y entorno de trabajo

2.1 Crear y activar venv (Windows / macOS / Linux)

3 Paso 1 — Tu primera aplicación en Flask

3.1 Rutas, respuestas y debug seguro

3.2 Plantillas con Jinja2: layout y bloques

4 Paso 2 — Persistencia mínima: SQLite + (opcional) SQLAlchemy

5 Paso 3 — Despliegue sencillo

5.1 Hosting/cPanel: app WSGI lista para producción

5.2 Easypanel en VPS (Hosting TG): Nixpacks vs Dockerfile

6 Extensiones útiles y estructura de proyecto

7 Errores comunes y cómo evitarlos

8 Sobre Flask

9 FAQs

Qué es Flask

Flask es, en mis palabras, un microframework web en Python con un núcleo pequeño y muy fácil de extender. A diferencia de frameworks “baterías incluidas”, no trae ORM por defecto ni decisiones rígidas sobre cómo estructurar tu proyecto; tú eliges piezas como SQLAlchemy, Marshmallow o lo que prefieras. En mi caso, esta ligereza me permite arrancar una idea en minutos y solo añadir lo que necesito.

Flask funciona sobre WSGI (la interfaz estándar para apps web en Python). Por debajo usa Werkzeug para la parte WSGI/routing y Jinja2 como motor de plantillas: justo las dos características que más suelo destacar cuando explico Flask a alguien nuevo. Históricamente, el proyecto fue creado por Armin Ronacher dentro del grupo Pocoo, y esa filosofía minimalista pero potente se mantiene hasta hoy.

¿Cuándo elegir Flask?

Si quieres control fino sobre tu stack (ORM opcional, autenticación a tu gusto, etc.).
Para APIs y prototipos rápidos.
Si prefieres aprender los conceptos web base (WSGI, routing, plantillas) sin que el framework lo oculte.

¿Cuándo no?

Cuando quieras un ecosistema “todo hecho” desde el día 1 (p. ej., un admin automático). En ese caso, compara con Django o FastAPI según tu caso de uso.

Requisitos previos y entorno de trabajo

Antes de escribir código, prepara entorno y dependencias.

Checklist rápido

Python 3.10+ instalado.
venv para aislar paquetes.
Editor (VS Code / PyCharm) con extensiones de Python.
Git y una cuenta en GitHub o GitLab (opcional pero recomendable).

Crear y activar venv (Windows / macOS / Linux)

# Crea la carpeta del proyecto
mkdir mi-flask-app && cd mi-flask-app

# Crea un entorno virtual
python -m venv .venv

# Activa el entorno
# Windows (PowerShell)
.venv\Scripts\Activate.ps1
# macOS / Linux
source .venv/bin/activate

# Instala Flask
pip install flask
pip freeze > requirements.txt

Nota de experiencia: al ser un microframework, Flask no incluye ORM ni capas extra; esa simplicidad hace que el venv y el requirements.txt sean tu “contrato” de dependencias desde el primer minuto.

Paso 1 — Tu primera aplicación en Flask

Crea un archivo app.py con la mínima app funcional:

from flask import Flask, render_template

app = Flask(__name__)

@app.route("/")
def home():
    return "¡Hola Flask! 🚀"

if __name__ == "__main__":
    app.run(debug=True)

Ejecuta:

flask --app app run
# o bien
python app.py

Rutas, respuestas y debug seguro

Rutas: En Flask defines rutas con @app.route. Esa facilidad de enrutamiento es una de las funciones que más valoro; te deja mapear URL a funciones de forma muy legible.
Respuestas: puedes devolver texto plano, JSON (return {"ok": True}) o plantillas HTML.
Debug: debug=True es cómodo en local, pero desactívalo en producción para no exponer información sensible.

Plantillas con Jinja2: layout y bloques

Crea la carpeta templates/ y un layout base:

templates/base.html

<!doctype html>
<html lang="es">
<head>
  <meta charset="utf-8" />
  <title>{% block title %}Mi Flask App{% endblock %}</title>
  <link rel="stylesheet" href="{{ url_for('static', filename='styles.css') }}">
</head>
<body>
  <header><h1>Mi Flask App</h1></header>
  <main>
    {% block content %}{% endblock %}
  </main>
  <footer><small>Powered by Flask</small></footer>
</body>
</html>

templates/home.html

{% extends "base.html" %}
{% block title %}Inicio{% endblock %}
{% block content %}
  <h2>Bienvenido</h2>
  <p>Renderizado con Jinja2.</p>
{% endblock %}

Y en app.py:

@app.route("/bienvenida")
def bienvenida():
    return render_template("home.html")

En mi experiencia, Jinja2 junto con el routing de Flask es lo que te permite pasar de un “hola mundo” a páginas reales sin fricción. Plantillas limpias y herencia de layouts = desarrollo más rápido.

Paso 2 — Persistencia mínima: SQLite + (opcional) SQLAlchemy

Puedes empezar con SQLite para no complicarte.

pip install sqlalchemy

models.py

from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.orm import declarative_base, sessionmaker

engine = create_engine("sqlite:///app.db", echo=False, future=True)
Base = declarative_base()
SessionLocal = sessionmaker(bind=engine, autoflush=False, autocommit=False)

class Nota(Base):
    __tablename__ = "notas"
    id = Column(Integer, primary_key=True)
    titulo = Column(String(120), nullable=False)

def init_db():
    Base.metadata.create_all(engine)

app.py (extracto)

from flask import Flask, request, redirect, url_for, render_template
from models import SessionLocal, init_db, Nota

app = Flask(__name__)
init_db()

@app.route("/notas", methods=["GET", "POST"])
def notas():
    db = SessionLocal()
    if request.method == "POST":
        titulo = request.form.get("titulo")
        if titulo:
            db.add(Nota(titulo=titulo))
            db.commit()
        return redirect(url_for("notas"))
    data = db.query(Nota).all()
    db.close()
    return render_template("notas.html", notas=data)

templates/notas.html

{% extends "base.html" %}
{% block title %}Notas{% endblock %}
{% block content %}
  <h2>Notas</h2>
  <form method="post">
    <input name="titulo" placeholder="Título de la nota" required />
    <button type="submit">Crear</button>
  </form>
  <ul>
    {% for n in notas %}
      <li>{{ n.id }} — {{ n.titulo }}</li>
    {% endfor %}
  </ul>
{% endblock %}

Aquí retomo tu idea: Flask no impone ORM. Puedes usar SQLAlchemy, consultas raw o incluso otro backend. Esa libertad es una seña de identidad del framework.

Buenas prácticas rápidas

Variables de entorno para secretos (p. ej., FLASK_SECRET_KEY).
Validar entradas (formularios) y manejar errores (400/404/500).
Estructurar en paquetes: app/, app/routes/, app/templates/, etc.

Paso 3 — Despliegue sencillo

Hosting/cPanel: app WSGI lista para producción

Si usas hosting con cPanel o similar:

Crea un virtualenv en el servidor e instala dependencias (pip install -r requirements.txt).
Crea un archivo wsgi.py

from app import app as application

Configura la aplicación Python (en cPanel: Setup Python App) apuntando a tu wsgi.py.
Usa un servidor WSGI en producción (Gunicorn/uwsgi) detrás de Nginx/Apache. Evita el server de desarrollo.

Variables de entorno

Configura FLASK_ENV=production y tu SECRET_KEY.
Gestiona .env con python-dotenv si lo prefieres.

Easypanel en VPS (Hosting TG): Nixpacks vs Dockerfile

En Hosting TG contáis con VPS con Easypanel donde puedes instalar Python y Flask con apenas unos clics desde Servicios → Aplicación. Eso acelera muchísimo el time-to-deploy.

Opción A — Nixpacks (cero Dockerfile)

Crea una app en Easypanel → Servicios → Aplicación → elige tu repo.
Easypanel detecta Python y genera la build.
Define el comando de ejecución (p. ej., gunicorn -w 2 -b 0.0.0.0:8000 app:app).
Añade variables de entorno (SECRET_KEY, DB_URL).
Expón el puerto y activa HTTPS con un clic.

Opción B — Dockerfile (control total)
Dockerfile

FROM python:3.12-slim
WORKDIR /app
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["gunicorn","-w","2","-b","0.0.0.0:8000","app:app"]

Sube la imagen o conecta el repo; Easypanel construye y despliega.
Recomendado si necesitas builds reproducibles o dependencias del sistema.

Experiencia personal: como Flask es WSGI y su núcleo es pequeño, encaja perfecto con ambos flujos. Si vienes de “probar ideas rápido”, Nixpacks te deja en producción en minutos; si necesitas ajustes finos, Dockerfile es tu amigo.

Checklist de producción

Server WSGI (Gunicorn/uwsgi), no flask run.
Logs y monitoreo (healthchecks, alerts).
HTTPS habilitado.
Backups automáticos (si usas SQLite, respalda el archivo; si usas Postgres, snapshots).
Variables de entorno seguras y rotadas.

Extensiones útiles y estructura de proyecto

Extensiones populares

Flask-Login (autenticación), Flask-WTF (formularios), Flask-Migrate (migraciones con Alembic), Flask-Caching (caché), Flask-CORS (APIs).

Estructura sugerida

mi-flask-app/
  app/
    __init__.py
    routes/
      __init__.py
      web.py
      api.py
    templates/
    static/
    models.py
    config.py
  tests/
  requirements.txt
  wsgi.py
  Dockerfile
  .env

Como Flask es un microframework, la estructura no es impuesta. Yo recomiendo separar rutas web/API, plantillas y modelos para crecer sin dolor.

Errores comunes y cómo evitarlos

Usar el servidor de desarrollo en producción. Solución: Gunicorn/uwsgi + Nginx/Apache.
Dejar DEBUG=True en producción. Solución: variable de entorno y DEBUG=False.
No versionar requisitos. Solución: pip freeze > requirements.txt y revisiones periódicas.
Olvidar variables de entorno (secretos en el código). Solución: .env + gestor de secretos del proveedor.
No probar migraciones. Solución: Flask-Migrate y un ciclo staging → prod.

Sobre Flask

Flask te da velocidad sin encadenarte a un stack rígido. Con un par de rutas y Jinja2 levantas una web usable; añades SQLite/SQLAlchemy para persistir y, cuando toque, la llevas a producción con un servidor WSGI. Si además tienes VPS con Easypanel en Hosting TG, el paso de “mi idea funciona” a “mi idea está online con HTTPS” son literalmente unos clics (Servicios → Aplicación), y eso —créeme— marca la diferencia.

FAQs

¿En qué se diferencia Flask de Django o FastAPI?
Flask es minimalista y WSGI; Django es “baterías incluidas”; FastAPI (ASGI) está muy orientado a APIs de alto rendimiento y type hints.

¿Necesito un ORM con Flask?
No. Puedes usar SQLAlchemy o consultas SQL directas. La gracia de Flask es que no impone.

¿Cómo paso de flask run a producción?
Usa un servidor WSGI (Gunicorn/uwsgi) detrás de Nginx/Apache. En Easypanel, configura el comando de arranque y variables de entorno.

¿Cómo organizo un proyecto para crecer?
Separa routes (web/API), plantillas, modelos y configuración. Añade tests, migraciones y un CI simple.

Opinión Personal

Confieso que, después de probar de todo, sigo volviendo a Flask cuando quiero ir de la idea al “online” sin fricción. Su filosofía de microframework me parece honesta: núcleo pequeño, decisiones mínimas y libertad total para elegir ORM, autenticación o estructura. Esa combinación—routing claro y Jinja2 para plantillas—me ha dado más velocidad real que muchos “todo en uno”. ¿El precio? Asumir responsabilidad: tú decides el stack y eso exige criterio.

A nivel práctico, mi receta ganadora es simple: venv, dependencias ordenadas, SQLite/SQLAlchemy para empezar y un servidor WSGI en producción (nada de flask run). Y si hablamos de despliegue, tener VPS con Easypanel es un cambio de juego: en Hosting TG, desde Servicios → Aplicación levanto la app, configuro variables y activo HTTPS en minutos. Para prototipos o MVPs, esa rapidez pesa más que cualquier benchmark.

¿Es Flask perfecto? No. Si buscas un admin de fábrica o una arquitectura rígida, quizá te compense Django. Pero si valoras el control y aprender los cimientos web —sin capas que oculten cómo funciona todo—, Flask es una apuesta sólida y, sobre todo, sostenible a medio plazo.

Ahora te toca: ¿por qué eliges tú Flask (o por qué no)? ¿Qué te ha funcionado mejor en despliegues: Nixpacks o Dockerfile? Déjame tus dudas y experiencias en los comentarios; te leo y respondo.