Pular para o conteúdo
Saiku Cloud

Self-hosting do Saiku

O Saiku distribui um build self-hosted sob Apache 2.0 + EPL — o mesmo build que rodamos no Saiku Cloud. Todo recurso que está no repositório OSS está no binário self-hosted. Sem SKUs enterprise, sem camada MCP com gate, sem conector Excel só-Cloud.

O trade-off é responsabilidade operacional: você roda a caixa, você lida com updates, você é dono dos backups. Esta seção é o playbook atual do operador.

Qual build pegar

DistribuiçãoQuando usá-la
ghcr.io/spiculedata/saiku:developmentAcompanha a branch development — novos recursos chegam aqui primeiro. Melhor para avaliação e deployments não-críticos.
ghcr.io/spiculedata/saiku:4.6.2 (fixe numa versão)Aponte para uma tag imutável. Recomendado para qualquer coisa rodando em produção.
saiku-dist-<version>.zip de ReleasesFat-JAR executável em Java 21 + wrappers run.sh/run.bat. Para times que não rodam Docker.

Tudo abaixo assume a imagem Docker; o fluxo do fat-JAR são as mesmas env vars + os mesmos volume mounts, menos o container.

Primeiro boot

  1. Puxe a imagem e inicie-a com um volume saiku-home persistente e uma senha de admin. O Saiku se recusa a servir enquanto as credenciais default admin/admin estiverem inalteradas, então defina sua senha logo no primeiro boot com SAIKU_ADMIN_PASSWORD:

    Terminal window
    docker volume create saiku-home
    docker run -d --name saiku \
      --restart unless-stopped \
      -p 8080:8080 \
      -v saiku-home:/app/saiku-home \
      -e SAIKU_HOME=/app/saiku-home \
      -e SAIKU_ADMIN_PASSWORD='a-strong-password' \
      ghcr.io/spiculedata/saiku:4.6.2

    No primeiro boot, o Saiku a hasheia com bcrypt em saiku-home/users.properties no volume. A variável de ambiente só é necessária na primeira vez — ela persiste entre reinícios, então você pode removê-la depois (ou deixá-la; redefini-la apenas reaplica a mesma senha).

  2. Abra http://localhost:8080/ui/ e faça login como admin com a senha que você definiu.

  3. Adicione seu primeiro datasource em Admin → Connections. Postgres, MySQL, BigQuery, Snowflake, ClickHouse, DuckDB, MotherDuck e H2 estão conectados out of the box.

Dimensionamento

Regras de bolso, extraídas de deployments reais. Cada dimensão escala independentemente — a maioria dos gargalos aparece na camada do warehouse, não no container do Saiku.

Formato de deploymentRAMCPUHeap JVM (-Xmx)
Avaliação / demo2 GB1 vCPU1 GB (default)
Time pequeno (< 20 usuários)4 GB2 vCPU2 GB
Médio (20-100 usuários)8 GB4 vCPU4 GB
Grande (100+ usuários)16 GB+8 vCPU8 GB
Workload AI pesado+50% de RAM sobre a base+2 vCPU sobre a baseIguale a base

Disco: /app/saiku-home cresce com sua contagem de workbooks e retenção de histórico de query. 20 GB é confortável para a maioria dos deployments single-tenant; escale para 100 GB+ se você está mantendo anos de histórico de auditoria.

Heap JVM: definido via -e JAVA_OPTS="-Xmx4g" na linha docker run. O heap default é intencionalmente conservador — aumente-o se você vê OutOfMemoryError em saiku-home/logs/.

Upgrades

O Saiku segue semver: 4.5.2 → 4.5.3 é patch, 4.5 → 4.6 é minor, 4.x → 5.x é major. Upgrades minor e patch são drop-in — puxe a nova imagem, reinicie o container, seu volume saiku-home carrega cada workbook e conexão adiante.

  1. Faça snapshot do volume primeiro (veja Backups abaixo — faça isso antes de cada upgrade).

  2. Pare o container em execução.

    Terminal window
    docker stop saiku && docker rm saiku

  3. Puxe a nova tag e inicie-a contra o mesmo volume.

    Terminal window
    docker pull ghcr.io/spiculedata/saiku:4.5.3
    docker run -d --name saiku \
      --restart unless-stopped \
      -p 8080:8080 \
      -v saiku-home:/app/saiku-home \
      ghcr.io/spiculedata/saiku:4.5.3

  4. Cheque o changelog para quaisquer notas de migração na versão que você acabou de instalar. A maioria dos releases não tem nenhuma; os que carregam peso são chamados explicitamente no topo da entrada.

Fazer rollback é o reverso: docker pull uma tag mais antiga, reinicie contra o mesmo volume. Compatível contanto que você não tenha cruzado uma versão major — o changelog sinaliza as incompatíveis.

Backups

saiku-home guarda tudo que vale a pena fazer backup: conexões, workbooks, queries salvas, usuários, histórico de auditoria, metadados de tenant. Faça backup dele na mesma cadência que qualquer outra coisa na sua plataforma de dados.

Snapshot de volume Docker (simples):

Terminal window
# Once
docker run --rm \
  -v saiku-home:/data \
  -v $(pwd):/backup \
  alpine tar czf /backup/saiku-home-$(date +%F).tar.gz -C /data .


# Restore
docker run --rm \
  -v saiku-home:/data \
  -v $(pwd):/backup \
  alpine tar xzf /backup/saiku-home-2026-07-10.tar.gz -C /data

Backups agendados (cron Linux):

Terminal window
0 2 * * * /usr/local/bin/saiku-backup.sh

Onde saiku-backup.sh roda o comando docker run --rm ... alpine tar ... acima e rotaciona arquivos antigos (find /backup -mtime +30 -delete).

Armazenamento fora da caixa. O snapshot de volume é um tarball simples — faça rsync dele para S3, wasabi ou qualquer object store num schedule. Replicação cross-region se você precisar.

Point-in-time recovery exige um backup do lado do warehouse dos dados que o Saiku consulta. O próprio estado do Saiku é pequeno (metadados + queries salvas); perder 24 horas dele é geralmente recuperável do último backup + arquivos de schema commitados no git.

Autenticação

Out of the box, o Saiku vem com auth in-memory respaldado por users.properties — bom para avaliação, substitua antes da produção. Três caminhos de substituição, em ordem crescente de esforço de integração:

  1. Usuários autoritativos file-backed. A senha de admin fica em saiku-home/users.properties no volume (o launcher a escreve lá a partir de SAIKU_ADMIN_PASSWORD no primeiro boot). Edite esse arquivo para adicionar contas — as entradas são user={bcrypt}$2y$...,ROLE_USER,ROLE_ADMIN; gere um hash com htpasswd -nbBC 12 <user> '<password>'. Para rotacionar a senha de admin depois, reinicie com um novo SAIKU_ADMIN_PASSWORD, ou edite o arquivo diretamente e reinicie. O store embutido é somente-leitura para as telas de gestão de usuários da UI de admin.
  2. LDAP / Active Directory. Config padrão de LDAP do Spring Security em applicationContext-security-ldap.xml. Veja o guia de wiring LDAP (link em breve).
  3. SSO SAML 2.0. Conectado via Spring Security SAML. Guia de wiring (link em breve).
  4. OAuth 2.0 / OIDC. Mesma história via Spring Security OIDC. Guia de wiring (link em breve).

O Saiku Cloud usa o caminho SAML com Auth0 como IdP; a config é a mesma que é distribuída no build OSS.

Observabilidade

O Saiku vem com OpenTelemetry opt-in — nenhum dado deixa a caixa a menos que você configure. Para ligá-lo, aponte o endpoint OTLP para seu collector:

Terminal window
docker run -d --name saiku \
  -e OTEL_EXPORTER_OTLP_ENDPOINT="https://otel-collector:4317" \
  -e OTEL_SERVICE_NAME="saiku-prod" \
  ghcr.io/spiculedata/saiku:4.6.2

O agente Java auto-instrumenta:

  • Jetty (request / response HTTP)
  • Jersey (endpoints REST)
  • JDBC (cada query SQL ao seu warehouse — cuidado com a cardinalidade)
  • java.net.http.HttpClient (chamadas ao provider de LLM, MCP outbound)
  • Log4j 2 (trace_id/span_id no MDC)
  • Métricas de JVM (heap, GC, threads)
  • Estatísticas do pool de conexão DBCP2

Sem a env var, o agente nunca é carregado. Zero overhead quando a observabilidade está desligada.

Configuração

Toda configuração é uma variável de ambiente padrão do SDK OpenTelemetry — o Saiku as passa direto para o agente. As que você vai realmente usar:

VariávelDefaultPropósito
OTEL_EXPORTER_OTLP_ENDPOINTnão-definidoURL do collector OTLP. Definir isto é o que ativa o agente. gRPC (:4317) ou HTTP/protobuf (:4318).
OTEL_EXPORTER_OTLP_PROTOCOLgrpcgrpc ou http/protobuf — case com seu collector.
OTEL_SERVICE_NAMEsaikuIdentificador de serviço na sua UI de tracing.
OTEL_RESOURCE_ATTRIBUTESnão-definidoex.: deployment.environment=prod,service.version=4.5.2.
OTEL_METRICS_EXPORTERotlpotlp / prometheus / none.
OTEL_EXPORTER_OTLP_HEADERSnão-definidoPara collectors SaaS que precisam de auth: api-key=….
OTEL_TRACES_SAMPLERparentbased_always_onEstratégia de sampling — veja abaixo.

Sampling. O default captura cada trace — certo para a demo, errado sob carga. Para produção, faça sampling de root traces:

Terminal window
export OTEL_TRACES_SAMPLER=parentbased_traceidratio
export OTEL_TRACES_SAMPLER_ARG=0.05   # 5% of root traces; children follow the root

Tenda a 1–5% para backends SaaS cobrados por uso; um Tempo ou Jaeger self-hosted lida com 25–100% confortavelmente no volume de query típico do Saiku.

Quando escalar para o Cloud

Self-hosted é a opção honesta para times que podem prover pessoal para ele. Limiares aproximados onde a economia do Cloud começa a vencer:

  • Você precisa de isolamento multi-tenant. O isolamento de tenant do Cloud (auditoria + billing + escopo de conexão) é uma camada de plataforma substancial em cima do build OSS. Viável de construir você mesmo; não barato.
  • Você precisa de auditoria + integração SIEM que você não quer rodar.
  • Você precisa de SSO com SLAs. Self-host + Auth0 funciona, mas se você ainda não tem um IdP rodando, o Cloud é mais rápido do que subir um.
  • Você quer SOC 2 sem fazer o trabalho de compliance. O alvo do Cloud é Q4 2026 (veja a página de postura de segurança).

Obtendo ajuda

Se você está avaliando self-hosted vs Cloud e quer uma segunda opinião, marque uma call de 30 minutos — respostas honestas, sem assinar contrato.