Voltar ao portfólio

Produto

Stackport

Sua VPS. Todos os seus apps. Zero trabalho braçal.

Para quem já paga uma VPS e roda mais de um app nela. O Stackport faz deploy de projetos Docker Compose do GitHub com HTTPS, registra os deploys para rollback e mostra o status dos serviços. Uso o Stackport para operar este site e outros serviços web da MattediWorks na minha VPS.

Código aberto · self-hosted

SiteGitHub

Do repositório ao serviço no ar

Conecte um repositório e uma branch do GitHub, faça deploy dos serviços Docker Compose e aponte um domínio para o serviço que deve receber o tráfego. O mesmo console reúne o commit em uso, a saúde, os logs e o terminal dos containers junto do app.

Em uso na MattediWorks

Time
Sozinho, do design ao deploy
Período
2026-09 – atual
Status
Em uso diário nos serviços da MattediWorks
Stack
TypeScript, Node.js, Express, React, SQLite, Docker

Publicar, acompanhar, restaurar

  • Push e deploy

    Conecte um repo do GitHub e escolha a branch. Cada commit novo vira um deploy fixado no commit exato.

  • HTTPS resolvido

    Aponte um domínio para um serviço e uma porta. nginx e certificados Let's Encrypt, emitidos e renovados, ficam por conta dele.

  • Rollback sem medo

    Todo deploy que dá certo guarda origem, config do Compose, branch e commit, pronto para restaurar.

  • Saiba o que está de pé

    Health check, tempo de resposta, CPU, memória e estado dos containers num painel só, mais logs e terminal no browser.

  • Verificações na política de deploy

    A política de deploy rejeita arquivos Compose que publicam portas no host, usam a rede do host, pedem containers privilegiados ou montam caminhos bloqueados do host.

  • Pronto para agentes

    Um MCP server deixa seu agente de IA consultar status, projetos e deploys recentes.

Mantendo um host administrável

  • Sem porta no host, fail-closed

    Um projeto cujo Compose publica porta ou usa rede do host é rejeitado no deploy, com um erro que aponta para expose:. Quem decide o que o host expõe é o Stackport, não o projeto. Custa um pouco de atrito para adaptar um repo e elimina uma classe inteira de exposição acidental.

  • Domínio aponta para serviço e porta, não para projeto

    Cada domínio mapeia para um par (serviço, porta do container) dentro do projeto, então um projeto pode servir o web app num domínio e a API de admin em outro. A mudança de rede que faz isso funcionar é uma reescrita efêmera do Compose, nunca commitada no repo do projeto.

  • Tudo em Docker, nada instalado no host

    Sem nginx, Certbot ou Node.js no host: ele só precisa de Docker, da CLI e de dois diretórios de estado. A configuração do nginx é gerada, validada e revertida se falhar, então um domínio errado nunca derruba o proxy dos outros projetos.

Serviços do sistema e apps gerenciados

O tráfego da internet chega no stackport-nginx, que serve o app Stackport (UI de admin, API e MCP) e faz proxy de cada projeto implantado pela rede stackport-proxy. O Stackport comanda o Docker Engine para implantar e rodar os projetos, cada um com seu próprio projeto Compose.Plano do sistemastackport-proxy80 · 443admin · API · MCPdeployInternetHTTP/S · TCPStackportExpress · React · SQLitestackport-nginxTLS · Let's EncryptDocker Enginecompose · logs · execProjeto ACompose próprioProjeto BCompose próprio
  • Backend Node/Express e client React em TypeScript; estado em SQLite.
  • O plano do sistema (Stackport e o nginx dele) é um projeto Compose; cada projeto implantado é outro, separado.
  • Os projetos entram numa rede compartilhada stackport-proxy; o nginx chega neles pelo nome do serviço.
  • Uma CLI stackport cuida de instalação, upgrade e recuperação de admin no host.
  • MCP server para agentes. Um projeto irmão, o Stackport MQTT, roda o broker Mosquitto só com TLS dos dispositivos NightMare e a API de controle dele em Go.

Até onde a plataforma vai

  • Um host só: sem distribuir entre máquinas.
  • A saúde aparece como "unknown" em projetos sem health check configurado.