Documentação

Como funciona

O GoLive gira à volta de projectos. Um projecto é uma app com o seu subdomínio <slug>.golive.ao e SSL automático. Fazes deploy, ligas serviços e pagas só o que usas — sem servidores para gerir.

• Deploy — envias o código com golive deploy ou por git push (GitHub connect). Cada deploy é imutável e a activação é atómica: o tráfego passa para a versão nova de uma vez, sem downtime, e voltas atrás num clique.
• Onde corre — o runtime é detectado automaticamente. Sites estáticos e edge functions correm na borda; backends (Node, Go, Next.js SSR) em contentores geridos. No Free só sites estáticos; backends e edge functions exigem o pague por uso.
• Serviços — cada projecto pode ligar Postgres, autenticação e armazenamento. No Free há tectos (100 MB DB, 100 users, 1 GB). No pague por uso escalas e desbloqueias backends/edge/domínios.
• Facturação — no pague por uso medimos invocações, MAU, armazenamento e banda, e facturamos no dia 28 (ver Planos & facturação). No Free, ao atingir um limite a API devolve quota_exceeded.

Fazes tudo pelo dashboard (app.golive.ao) ou pela CLI (golive). A CLI faz tudo o que o dashboard faz — ideal para automação e CI.

O primeiro deploy

Cria a conta em app.golive.ao e um projecto no dashboard. No Free o primeiro deploy deve ser um site estático (React/Vite, HTML…); backends e edge functions pedem pague por uso. Depois instala a CLI:

$ npm install -g https://golive.co.ao/cli/golive-cli.tgz
$ golive login
$ golive init          # liga a pasta actual a um projecto
$ golive deploy

No fim do deploy recebes o URL público do projecto — https://<slug>.golive.ao — já com SSL. Se a pasta tiver um golive.json (criado pelo init), não precisas de passar --project em mais nenhum comando.

O deploy para produção pede confirmação. Usa --yes para saltar (útil em CI) — o exit code é sempre ≠ 0 em falha.

A CLI

Todos os comandos aceitam --project <id> (ou usam o golive.json da pasta) e --json para output legível por máquinas.

📖 Referência completa, comando a comando, com todos os argumentos, opções e exemplos: CLI golive. A tabela abaixo é o resumo.

Activa o auto-complete por Tab uma vez — os comandos, opções e os seus placeholders aparecem enquanto escreves:

# zsh
$ echo 'source <(golive completion zsh)' >> ~/.zshrc
# bash
$ echo 'source <(golive completion bash)' >> ~/.bashrc
# fish
$ golive completion fish > ~/.config/fish/completions/golive.fish

O ficheiro golive.json

O golive init escreve um golive.json na raiz da pasta, a ligá-la ao projecto:

{
  "projectId": "a1b2c3d4"
}

Com este ficheiro presente, todos os comandos usam o projecto automaticamente — não precisas de --project. Comita-o no repositório para a equipa (e o CI) partilharem o mesmo alvo.

Além do projectId, o golive.json pode fixar afinações que de outra forma passarias por flags — útil para reprodutibilidade na equipa e no CI. Tudo é opcional (o zero-config continua a funcionar) e a precedência é sempre flag > golive.json > automático. Exemplo com todos os campos:

{
  "projectId": "a1b2c3d4",

  // override do que o detector adivinha (só se precisares)
  "outputDir": "build",          // pasta a publicar (estático)
  "functionsDir": "api",          // pasta das edge functions

  // preferências do `golive dev`
  "dev": {
    "port": 18321,              // porta base (multi-alvo incrementa: 18322…)
    "open": false,              // não abrir o browser no arranque
    "seed": "seed.sql",         // SQL corrido no arranque da DB local

    // Dev Pack: que serviços locais arrancar (`golive dev init` escreve isto)
    "emulators": {
      "auth": true,             // /__golive/auth + utilizadores no painel
      "database": true,         // Postgres local (pglite) + DATABASE_URL
      "storage": true,          // ficheiros em .golive/dev/storage
      "functions": false        // pasta functions/ no mesmo host que o site
    }
  }
}

Referência dos campos

Omissões do Dev Pack: se declarares dev.emulators, cada serviço é opt-in (só arranca com true). Se não declarares o bloco (projectos antigos), o auth e o storage arrancam por omissão e a database só com --db. Corre golive dev init para escolher num menu.

dev.db: true ainda funciona, mas está descontinuado — usa dev.emulators.database.

Nunca ponhas segredos aqui — o golive.json é comitado. Chaves e passwords vão por golive env (ficam do lado do servidor, nunca no git).

Monorepo: vários projectos num repo (multi-alvo)

Tens um site e uma API (ou várias apps) no mesmo repositório? Em vez de um projectId, define apps — cada uma com a sua pasta e o seu projecto. Cada app aceita os mesmos campos do nível de topo (projectId, outputDir, functionsDir, dev), mais dir:

{
  "apps": {
    "site": {
      "dir": "web",              // raiz da app (relativa ao golive.json)
      "projectId": "…",
      "outputDir": "dist",
      "dev": { "port": 18321 }
    },
    "api": {
      "dir": "api",
      "projectId": "…",
      "functionsDir": "functions",
      "dev": { "port": 18322, "emulators": { "database": true } }
    }
  }
}

Cria o esqueleto com golive init --apps site:web,api:api (e preenche os projectId). Depois:

• golive deploy na raiz → publica todas as apps; golive deploy api → só uma.
• golive dev na raiz → corre todas as apps (cada uma na sua porta); golive dev api → só uma.
• Os restantes comandos (golive env, db, storage, auth, logs…) escolhem a app pela pasta onde estás: cd web && golive env set… mexe no site; cd api && golive db create mexe na API. Na raiz, pedem-te para entrares numa app (ou usa --project).

Cada app tem o seu tipo (o detector corre por app) — ex.: web/ estático + api/functions/ edge. Resolve o caso de "site + funções no mesmo repo" com um só ficheiro.

Runtimes suportados

O runtime é detectado automaticamente a partir dos ficheiros do projecto — não há configuração. No Free só deploys estáticos (React/Vite, HTML…); Next.js SSR, Node, Go e edge functions exigem pague por uso.

Backends lêem a porta de process.env.PORT (Node) ou $PORT (Go). Deploy de backend/edge no Free devolve project_type_not_allowed.

Desenvolvimento local

Corre o teu projecto na tua máquina, igual à produção, com um só comando — e um painel para veres tudo (estilo emulador). Iteras localmente e só publicas quando estiver pronto. Nada remoto é tocado.

$ golive dev
  app:    http://localhost:18321            # a tua app
  painel: http://localhost:18321/__golive/  # o dashboard local

A porta base por omissão é 18321 (fora de Wrangler/Cloudflare 8787–8788, Vite 5173, Next 3000 e do stack local GoLive). Em multi-alvo, golive dev arranca todas as apps (18321, 18322, … ou apps.<nome>.dev.port). A env inclui GOLIVE_DEV_<APP>_URL e GOLIVE_DEV_APPS para o site chamar a API local.

Sites Vite/React (e outros com npm run build): o golive dev rebuilda o dist/ no arranque e sempre que gravas o source — não fiques com um build antigo. Sites HTML puros servem-se tal como estão.

GoLive Dev Pack

Serviços locais (Auth, Database, Storage, Functions) + painel — desenvolve com dados no disco.

$ golive dev init     # ↑/↓ navegar · Space ligar/desligar · Enter confirmar
$ golive dev          # arranca app + Dev Pack + painel /__golive/

Sem menu (CI/scripts): golive dev init --all liga tudo, --yes aceita os defaults, e --emulators auth,database escolhe à mão (ou all). Escreve o bloco dev.emulators no golive.json.

• Auth — cria utilizadores no painel; a app usa GOLIVE_AUTH_ENDPOINT.
• Database — Postgres (pglite) + DATABASE_URL; SQL no painel; seed.sql no arranque.
• Storage — upload no painel; ficheiros em .golive/dev/storage.
• Functions — pasta functions/ no mesmo host que o site (rotas exactas têm prioridade).

$ golive dev
  site         http://localhost:18321   static
  api          http://localhost:18322   edge
  painel: http://localhost:18321/__golive/

golive dev api corre só a app api. --port redefine a base (as outras incrementam se não tiverem dev.port).

Como serve a tua app

Deteta o runtime (o mesmo detector do deploy) e serve conforme o tipo:

• Edge functions — empacota cada handler (com as tuas deps npm) e corre-o no contrato Request→Response, com as mesmas rotas da produção (o mesmo mapa ficheiro→rota, o mesmo 404). Ao gravares um ficheiro, re-empacota e recarrega sozinho.
• Estático — serve a pasta de saída, com SPA fallback (rotas desconhecidas → index.html).
• Backend (Node/Go) — arranca o teu dev (ou start) numa porta livre e faz proxy, incluindo WebSockets, com a env do projecto injectada.

Serviços locais (base de dados, auth, ficheiros)

Emula os serviços geridos, para a app correr igual ao prod — só que local:

• Base de dados — golive dev --db arranca um Postgres local e injecta DATABASE_URL na app (edge e backend). Ligas-te com o driver de sempre.
• Autenticação — o SDK @golive/auth aponta para o emulador local; os utilizadores que crias ficam à mão no painel. No cliente, em dev:

  // os três endpoints apontam para o mesmo host do Dev Pack
  const base = "http://localhost:18321/__golive/auth";
  
  const auth = new GoLiveAuth({
    apiKey: "dev", tenant: "dev",
    endpoints: { // só em dev — em prod deixas em branco
      identity: `${base}/identity/v1`,
      secureToken: `${base}/token/v1`,
      controlPlane: base   // obrigatório: é por aqui que o signUp passa
    }
  });

  Sem o controlPlane o signIn funciona mas o signUp falha — é o control plane que aplica o tecto de utilizadores do plano.

• Armazenamento — ficheiros locais (em .golive/dev/storage), com API igual à do storage gerido e um explorador no painel.

O painel

Em /__golive/ (só localhost): sidebar com Overview, Auth, Storage, Database, Logs e Env. No Overview: URL da app, uptime, pedidos e serviços activos; em multi-alvo, lista de apps com link para o painel de cada uma. Auth traz snippet do SDK pronto a copiar; Env lista as variáveis injectadas (DATABASE_URL, GOLIVE_DEV_*…) com copiar/export. Atalhos: 1–6 para tabs, o para abrir a app.

Configurar

Por flags — --port <n>, --db, --no-open — ou fixa no golive.json (secção dev: port, open, seed e o bloco emulators) para não repetires. O golive dev init escreve o emulators por ti num menu:

{
  "dev": {
    "seed": "seed.sql",
    "emulators": { "auth": true, "database": true, "storage": true, "functions": false }
  }
}

Com isto, um simples golive dev sobe a base de dados, aplica o seed e liga o auth e o storage locais. Ver a referência completa dos campos.

Edge Functions

Edge functions exigem o plano pague por uso. São o backend gerido do GoLive: HTTPS, escala, CORS (allowlist *.golive.ao, localhost, domínio custom) e DATABASE_URL da DB GoLive (URL pooler). Para Mongo ou stack à tua medida, usa um backend Node/Go.

Uma pasta functions/ — cada ficheiro é uma rota. Node-compat no runtime (podes usar pg com Pool({ max: 1 })). Sem framework de app nem index.html; o golive deploy deteta o tipo automaticamente.

Escreve os handlers em TypeScript (.ts) ou JavaScript (.mjs) — o deploy compila e empacota por ti, sem tsconfig nem passo de build da tua parte. Cada ficheiro exporta um default no contrato Web/Fetch padrão: recebe um Request e devolve um Response (as APIs standard da Web que já conheces):

// functions/hello.ts  ->  /hello?name=Ana
export default async (request: Request) => {
  const name = new URL(request.url).searchParams.get("name") ?? "world";
  return Response.json({ hello: name });
};

Tens a Request inteira: request.method, request.url, request.headers e o corpo com await request.json() / request.text(). Devolves qualquer Response (Response.json(...), HTML, redirects, streams…).

Podes instalar dependências. Faz import de pacotes npm e de outros ficheiros — o deploy empacota tudo num módulo auto-contido por rota:

// functions/slug.ts
import slugify from "slugify";           // pacote npm
import { greet } from "./_lib.js";        // ficheiro teu

export default (request: Request) =>
  Response.json({ slug: slugify(greet("Olá Mundo")) });

Ficheiros ou pastas começados por _ (ex.: _lib.ts) são privados: podes importá-los, mas não viram rota. Depois de publicar, vês as rotas e o consumo:

$ golive deploy          # deteta edge-functions, empacota e publica
$ golive functions ls    # rotas + invocações/GB-s/Kz do período

Facturado por invocação: 1.648 Kz / 500 000.

Site estático + funções no mesmo repo

Um projecto é de um tipo só: estático ou edge functions. Uma pasta functions/ ao lado do index.html do site não vira função (ou vai como estático, ou é ignorada). Para teres os dois, cada um tem a sua própria raiz e é um projecto — declara-os como multi-alvo num só golive.json:

loja/
  golive.json           # { "apps": { "site": {"dir":"web"}, "api": {"dir":"api"} } }
  web/    index.html     # projecto estático
  api/    functions/     # projecto edge (sem index.html)

$ golive deploy         # publica as duas (ou `golive deploy api` só a API)
$ golive dev            # corre site + API (portas distintas)
$ golive dev api        # só a API

Ficam em subdomínios diferentes; o site chama as funções pelo URL da API (com CORS, se preciso). Cria a estrutura com golive init --apps site:web,api:api.

Ambientes & preview

Cada projecto tem dois ambientes:

• Produção (golive deploy --prod, ou --yes em CI) — serve o subdomínio público e o teu domínio próprio. Pede confirmação por omissão.
• Preview (golive deploy --preview) — publica em https://<slug>--preview.golive.ao, um endereço próprio com SSL. A produção não é tocada: o público continua a ver a versão anterior até fazeres deploy --prod.

Sem flag, o deploy pergunta qual queres. Em ambos, o deploy é imutável e fica no histórico (golive deploys). O rollback aplica-se à produção; um deploy de preview não é promovível — quando estiver pronto, publica com --prod.

GitHub connect

$ golive link --repo a-tua-org/loja-da-kia
✔ Repo ligado: a-tua-org/loja-da-kia@main
✔ Publicado: https://loja-da-kia.golive.ao

Depois de ligado, cada git push para a branch configurada dispara um deploy automático — o build corre do nosso lado (conta para os minutos de build do plano). Usa --no-deploy para ligar sem publicar já, e golive unlink para desligar.

O GitHub connect funciona com repos públicos; o suporte a repos privados chega com a app GitHub do GoLive. Para privados, hoje, usa golive deploy (CLI) — em CI também.

Deploys e rollback

Cada deploy é imutável e fica no histórico. A activação é atómica — o tráfego muda para a versão nova de uma vez, sem downtime. Para voltar atrás:

$ golive deploys          # lista o histórico
$ golive rollback         # volta ao deploy anterior

O rollback também está disponível no dashboard, no separador Deploys do projecto.

Domínios próprios

No dashboard, abre Domínios, adiciona o teu (ex.: www.lojadakia.ao) e cria os registos DNS que aparecem no ecrã, no teu registrar:

O certificado SSL é emitido automaticamente depois da validação (minutos, dependendo da propagação do DNS). Domínios próprios exigem o plano pague por uso.

Bases de dados

📘 Referência completa do SDK: @golive/data — query builder, filtros, sql(), rpc() e segurança.

No Free o React acede ao Postgres com @golive/data (Data API) + JWT — sem edge. Na edge: SDK com serviceKey ou pg + DATABASE_URL.

$ npm i https://golive.co.ao/sdk/golive-data-0.1.0.tgz

// Browser Free
import { GoLiveData } from "@golive/data";
const db = new GoLiveData({ projectId, apiKey, getToken: () => auth.getIdToken() });
const { data } = await db.from("profiles").select().maybeSingle();

No Free podes criar Postgres com tecto de 100 MB. Escritas SQL acima do tecto devolvem quota_exceeded. Num site Free usas a DB pela consola do dashboard, pela CLI, ou com a connection string em apps externas. Backends (Node/Go/Next) que injectam DATABASE_URL no deploy exigem o pague por uso.

$ golive db create     # Postgres gerido
✔ Base de dados criada

No pague por uso, no deploy seguinte o backend recebe DATABASE_URL no ambiente — liga-te com o driver normal do teu stack:

// Node — pg
import pg from "pg";
const db = new pg.Client({ connectionString: process.env.DATABASE_URL });
await db.connect();
const { rows } = await db.query("select * from clientes limit 10");

Um projecto tem uma base de dados; golive db info mostra os detalhes e golive db destroy apaga-a. Para ligar ferramentas externas (psql, um ORM), golive db url imprime a connection string completa — ex.: export DATABASE_URL=$(golive db url).

No dashboard, o separador Base de dados traz um SGBD completo: navegador de tabelas, grelha de dados com criar/editar/apagar linhas, vista de estrutura (colunas, índices, restrições), um construtor de tabelas visual e um editor SQL com realce de sintaxe e autocompletar. Pela CLI, corre SQL com golive db query (ou por stdin: cat schema.sql | golive db query).

Backups & restauro

$ golive db backup create            # backup imediato
$ golive db backup schedule daily    # ou weekly / off
$ golive db backup restore <id>      # repõe os dados

Cada backup é uma cópia lógica completa (tabelas, dados, sequências, índices e restrições), guardada comprimida e cifrada. Podes criá-los à mão ou agendá-los (diário/semanal); o restauro repõe a base de dados nesse ponto. Também disponível no dashboard, no separador Backups. Os backups retidos são cobrados como armazenamento (1.250 Kz/GB·mês).

Autenticação de utilizadores

📘 Referência completa do SDK: @golive/auth — configuração, todos os métodos, erros e Dev Pack local.

$ golive auth enable
✔ Autenticação activada

Adiciona login (email/password) à tua app com o auth gerido do GoLive — os teus utilizadores ficam isolados num tenant dedicado. No cliente usas o SDK @golive/auth (sem dependências), instalado a partir do GoLive:

$ npm i https://golive.co.ao/sdk/golive-auth-0.1.0.tgz

As chaves (apiKey + tenant) estão no separador Autenticação → Integrar no cliente do teu projecto. O SDK guarda a sessão e renova o token sozinho:

import { GoLiveAuth } from "@golive/auth";

const auth = new GoLiveAuth({
  apiKey: "AIza…",
  tenant: "…",
  controlPlane: "https://…/api",  // no snippet do dashboard
});

await auth.signUp(email, password);  // aplica tecto Free = 100 users
await auth.signIn(email, password);
const token = await auth.getIdToken();   // Authorization: Bearer <token>

auth.onChange((user) => console.log(user ? user.email : "sem sessão"));

Métodos: signUp, signIn, signOut, getIdToken, sendPasswordReset, updateProfile, onChange, currentUser. Sem passo de build, também podes import ... from "https://golive.co.ao/sdk/auth.js". Gere os utilizadores no dashboard ou pela CLI (golive auth users).

Limites: no Free, no máximo 100 utilizadores por projecto — signUp (SDK) e criação no dashboard/CLI passam pelo control plane e devolvem quota_exceeded ao atingir o tecto. No pague por uso a escala é maior; facturação por MAU: primeiros 1 000 activos/mês grátis, depois 100 Kz por MAU.

Armazenamento de ficheiros

📘 Referência completa do SDK: @golive/storage — upload, links temporários, ficheiros públicos e limites.

No Free a app (React) usa @golive/storage + Auth — sem edge. Na edge tens o mesmo SDK com serviceKey, ou a CLI/dashboard com o token de developer.

$ npm i https://golive.co.ao/sdk/golive-storage-0.1.1.tgz
$ golive storage upload logo.png imagens/logo.png
$ golive storage ls imagens/

// Browser (Free) — paths sob users/{uid}/
import { GoLiveStorage } from "@golive/storage";

const storage = new GoLiveStorage({
  projectId: "…",
  apiKey: "AIza…",
  getToken: () => auth.getIdToken(),
});

await storage.uploadFile("avatar.png", file);
const { url } = await storage.getDownloadUrl("avatar.png"); // ~1h

API: list, upload/uploadFile, getDownloadUrl, download, remove, usage. Upload ≤ 8 MB passa pela API (fiável no browser); maior usa URL assinado. Links de descarga são temporários (~1 hora) — não uses como CDN permanente. No dashboard, o separador Armazenamento tem explorador completo. Free: tecto 1 GB (site + ficheiros); PAYG: 1.250 Kz/GB·mês.

CDN ESM: https://golive.co.ao/sdk/storage.js. Dev Pack: POST /__golive/storage (CLI ≥ 0.8.2). Pasta public/ + getPublicUrl = URL permanente (/v1/public/files/…). Dashboard → Integrar no cliente.

Variáveis de ambiente

$ golive env set STRIPE_KEY=sk_live_...
$ golive env file .env   # envia um .env inteiro de uma vez
$ golive env ls
$ golive env pull        # escreve um .env local

golive env file <caminho> lê um ficheiro .env e envia todas as variáveis de uma só vez (aceita export, aspas e comentários). As variáveis são injectadas no backend no próximo deploy. Também podes geri-las no dashboard, no separador Variáveis do projecto. Nomes seguem o padrão MAIUSCULAS_COM_UNDERSCORE.

Logs

golive logs segue o build e o runtime em directo (sai com Ctrl-C; --no-follow imprime e sai). No dashboard, o separador Logs mostra o mesmo stream.

Planos e facturação

Resumo técnico abaixo. Para a página comercial com comparação de planos, tarifas e FAQ, vê golive.co.ao/precos.

Free

1 projecto estático com subdomínio *.golive.ao, SSL, CLI e GitHub. 1 GB de armazenamento, 20 min de build / mês, Postgres até 100 MB e auth até 100 utilizadores. Backends e edge functions não estão no Free — requerem pague por uso. Ao atingir um limite, a API responde quota_exceeded e a operação é recusada; o projecto não é suspenso.

Pague por uso

Backends, edge functions, mais projectos, domínios próprios e escala de DB/auth/storage. O uso é medido durante o mês e facturado no dia 28, com factura fiscal e o teu NIF.

Facturação proporcional ao uso — pagas exactamente o que consomes, sem mínimos. Os utilizadores activos (MAU) das tuas apps são grátis até 1 000 por mês.

• Saldo — carregas no dashboard; o saldo abate na factura do dia 28.
• Sem saldo no dia 28? Tens até ao dia 01 para carregar. Depois disso o serviço é pausado (os dados ficam guardados) e retoma quando o saldo entra.
• Limite de gastos — define um tecto mensal na Faturação; ao atingi-lo, a plataforma suspende os projectos sozinha.

Activar o pague por uso exige NIF (factura fiscal).

Limites

Precisas de mais? Escreve-nos: suporte@golive.ao.

Resolução de problemas

Como testo antes de publicar em produção?

Usa golive deploy --preview para publicar uma versão de teste sem tocar na produção. O deploy para produção pede sempre confirmação (salta com --yes).

O deploy falhou. O que faço?

Corre golive logs para veres o build e o runtime em directo — a maioria das falhas de backend é uma dependência em falta ou o comando de build. A CLI devolve exit code ≠ 0 em falha (útil no CI).

O meu backend não arranca.

O backend tem de escutar na porta de process.env.PORT (Node) ou $PORT (Go) — não uma porta fixa. Em Node, o deploy corre npm run build (se existir) e arranca com npm start — confirma que o start existe no package.json. O runtime é detectado pelos ficheiros (package.json, go.mod) na raiz. Precisas de controlo total? Comita um Dockerfile — se existir, é usado tal como está.

Como me ligo à base de dados a partir do código?

No Free: usa a consola, golive db query ou golive db url. No pague por uso, o backend recebe DATABASE_URL no deploy seguinte. Ver Bases de dados.

Onde vejo quanto estou a gastar?

No dashboard, em Faturação, com a repartição por recurso e o consumo do mês. Para funções, golive functions ls mostra as invocações e o custo do período. Define um limite de gastos para a plataforma travar sozinha.

Recebi quota_exceeded / project_type_not_allowed. O que significa?

Atingiste um tecto do plano ou tentaste um tipo de projecto não permitido. No Free: 1 site estático, 1 GB, 20 min build, Postgres 100 MB, Auth 100 users — sem backends nem edge functions. A operação é recusada; o projecto não é suspenso. Para mais capacidade, activa o pague por uso.

Esqueci-me do id do projecto.

golive projects lista todos (id, slug, nome). Dentro de uma pasta ligada, o golive.json já o guarda — não precisas do id.

Agent Skills

Agent skills são capacidades reutilizáveis para agentes de IA. Instala-as com um comando e o teu agente ganha conhecimento especializado sobre o GoLive — deploy, base de dados, autenticação, armazenamento e edge functions. Seguem a especificação aberta Agent Skills e funcionam com qualquer agente compatível.

Agentes compatíveis

Claude Code, TM Code, OpenAI Codex, GitHub Copilot, Cursor, Cline, Gemini, Windsurf — e qualquer agente que suporte a especificação agentskills.io.

Skills disponíveis

Instalação

npx ithustle/golive-skills (recomendado) — instalador próprio que cobre o Claude Code e o TM Code, incluindo os alvos que a CLI da Vercel não suporta (.toquemedia-studio/skills no projecto, ~/.toquemedia-studio/skills global):

# no teu projecto → .claude/skills/ + .toquemedia-studio/skills/
$ npx ithustle/golive-skills
# global (todos os projectos) → ~/.claude/skills/ + ~/.toquemedia-studio/skills/
$ npx ithustle/golive-skills --global
# só algumas
$ npx ithustle/golive-skills --only golive-deploy,golive-auth

npx skills add — a CLI da agentskills.io cobre outros agentes (Cursor, Codex, Windsurf, Cline, …), mas não o TM Code:

$ npx skills add ithustle/golive-skills -a claude-code -a cursor

O agente deteta os skills automaticamente ao iniciar. Basta pedires "faz deploy do meu projecto no GoLive" e o skill relevante é activado.

Skill: golive-deploy

Como pôr um projecto no ar: instalar a CLI, ligar a pasta (golive init), escolher o runtime, publicar para preview/produção, ligar o GitHub e voltar atrás com rollback.

Ideal para: o primeiro deploy, ligar CI por GitHub, ou automatizar publicações.

• 🚀 Instalar a CLI, golive login / init / golive.json
• 🧩 Detecção de runtime (Free: estático; PAYG: Next/Node/Go/edge)
• 📦 deploy --preview / --prod, GitHub connect, rollback
• 🔧 Variáveis de ambiente, domínios próprios, logs

Skill: golive-edge-functions

Escrever funções que correm na borda: uma pasta functions/ onde cada ficheiro é uma rota, handlers em TypeScript no contrato Web/Fetch (Request → Response), com import de pacotes npm e ficheiros teus.

Ideal para: APIs pequenas, webhooks, ou lógica na borda sem gerir servidores.

• 🗺 Mapa ficheiro → rota (functions/hello.ts → /hello); _ficheiro = privado
• 💻 Handler default: (request: Request) => Response
• ⚙ Compila e empacota no deploy; import de dependências npm
• 📊 Publicar e medir com golive functions ls

Skill: golive-database

Usar o Postgres gerido: criar (Free até 100 MB), explorar/editar no SGBD do dashboard, SQL pela CLI, e no pague por uso ligar o backend com DATABASE_URL e backups agendáveis.

Ideal para: persistência no site Free (consola/CLI) ou no backend PAYG.

• 🗄 golive db create; Free: 100 MB · PAYG: DATABASE_URL no backend
• 💻 golive db query (arg ou stdin) e o SGBD do dashboard
• 💾 Backups: create / schedule / restore

Skill: golive-auth

Adicionar login à tua app com o auth gerido: activar, usar o SDK @golive/auth no cliente (apiKey + tenant + controlPlane), gerir utilizadores e limites por plano.

Ideal para: adicionar autenticação sem montares um serviço próprio.

• 🔐 golive auth enable e as chaves do separador Integrar no cliente
• 💻 @golive/auth: signUp (com quota), signIn, getIdToken, onChange
• 👥 Free: 100 users/projecto; PAYG: escala + 1000 MAU grátis/mês

Skill: golive-storage

Guardar e servir ficheiros por projecto: carregar, listar, descarregar e apagar pela CLI ou pelo explorador do dashboard, com links temporários.

Ideal para: guardar assets do projecto ou ficheiros carregados pelos utilizadores.

• 📤 golive storage upload / ls / download / rm
• 🗂 Explorador no dashboard (pastas, arrasta-e-larga, copiar link)
• ⏳ Free: 1 GB · PAYG: 1 250 Kz/GB·mês; links temporários (1 h)

⚠ Segurança: revê sempre o conteúdo do SKILL.md antes de instalares skills de terceiros — um skill pode instruir o agente a executar código e a aceder a ficheiros do sistema.