Dica: build-essential/python3 ajudam a compilar módulos nativos quando necessário:
sudo apt install -y build-essential python3 make g++
2) Backup antes de atualizar
# pare o serviço se for copiar a instalaçãosudo systemctl stop foundry || true# backup do user data (mundos/módulos/config)tar -czf ~/foundrydata-backup-$(date +%F).tgz -C /home/ubuntu foundrydata
3) Baixar e instalar o Foundry v13 (Node)
Crie um diretório temporário, baixe o ZIP Node do v13 com sua URL licenciada e descompacte:
mkdir -p ~/foundry_v13 && cd ~/foundry_v13# exemplo com curl (use sua URL de download licenciada)curl -fSL -o foundry_node.zip "https://seu_link_licenciado/foundry_node_13.x.zip"unzip foundry_node.zip
Observação: nomes baixados podem vir com ?verify=.... Remova o arquivo após unzip.
Mova a instalação para o caminho definitivo (mantendo a anterior como foundry_old):
Acesse explicitamente por HTTP: http://SEU-IP:30000
ERR_SSL_PROTOCOL_ERROR ocorre quando você acessa https:// um servidor que está respondendo apenas http://. Use http:// ou configure o proxy TLS (Caddy) abaixo.
curl -I http://127.0.0.1:30000 # upstream local (302 /license ou 200)curl -I https://SEU-DOMINIO.duckdns.org # deve responder via Caddy (HTTP/2 302/200)
[Service]NoNewPrivileges=yesProtectSystem=fullProtectHome=truePrivateTmp=true# Liberar escrita apenas onde precisaReadWritePaths=/home/ubuntu/foundry /home/ubuntu/foundrydata /var/log
Atenção: se endurecer demais, o Node pode não conseguir ler/escrever onde precisa. Teste e ajuste ReadWritePaths.
10) (Opcional) Atualizador DuckDNS com systemd timer
sudo tee /usr/local/bin/duckdns-update.sh >/dev/null <<'EOF'#!/usr/bin/env bashDOMAIN="SEU-SUBDOMINIO" # ex.: foundry-pedroTOKEN="SEU_TOKEN"IP="$(curl -s -4 https://ifconfig.co)"curl -s "https://www.duckdns.org/update?domains=${DOMAIN}&token=${TOKEN}&ip=${IP}"EOFsudo chmod +x /usr/local/bin/duckdns-update.shsudo tee /etc/systemd/system/duckdns.service >/dev/null <<'EOF'[Unit]Description=DuckDNS updater[Service]Type=oneshotExecStart=/usr/local/bin/duckdns-update.shEOFsudo tee /etc/systemd/system/duckdns.timer >/dev/null <<'EOF'[Unit]Description=Run DuckDNS updater every 5 minutes[Timer]OnBootSec=1minOnUnitActiveSec=5minUnit=duckdns.service[Install]WantedBy=timers.targetEOFsudo systemctl daemon-reloadsudo systemctl enable --now duckdns.timersystemctl list-timers duckdns.timer
Com isso, você tem um fluxo reprodutível: atualização do núcleo, separação de dados, execução persistente, HTTPS automático por proxy e um arsenal de checagens para diagnosticar ERR_SSL_PROTOCOL_ERROR ou erros de emissão de certificado. Guarde este guia; quando pintar o mesmo sintoma, siga direto para as seções 5/6 (HTTP vs HTTPS) e 8 (Troubleshooting). Boa mesa! 🎲
Registro operacional — auditoria de compatibilidade D&D5e e v14 (2026-08-29)
Confirmado (auditoria local): a instalação local auditada usava Foundry VTT v13.351, D&D5e v5.2.5 e 263 módulos instalados. Antes de atualizar o sistema para D&D5e 5.3.x, é necessário conferir o manifesto (module.json) de cada módulo de automação e também a versão mais recente mantida pelo autor.
O levantamento identificou travas de versão na cópia então instalada de Tidy 5e Sheets (v12.5.5) e Plutonium (v3.14.3.noble-prerelease): ambas precisavam ser atualizadas junto com o sistema para não exceder o limite declarado para D&D5e 5.2.x. O mesmo levantamento registrou que as cópias então instaladas de Midi QOL, DAE, Gambit’s Premades e Automated Conditions 5e declaravam suporte a D&D5e 5.3.x; isso não substitui a nova leitura dos manifestos no momento da mudança.
Incidente conhecido — Dice So Nice exibe d6 em rolagens de d20
Confirmado (fonte do mantenedor): o issue #541 documenta que, com Foundry VTT 13.351, D&D5e 5.3.0 e Dice So Nice 5.2.5, uma rolagem por atributo/perícia podia ser renderizada visualmente como dado de seis faces em vez de d20. O relato trata a anomalia como visual; ele não valida automaticamente o resultado mecânico de uma rolagem específica.
Encaminhamento registrado (2026-09-02): antes de desatualizar D&D5e ou módulos de automação — incluindo Epic Roll(s) — testar o Dice So Nice 5.3.4 em uma cópia do mundo. A tag 5.3.4 registra correções adicionais para casos de dados customizados de sistemas. A relação exata entre a correção e cada módulo ativo deve ser confirmada no mundo de teste.
Para instalar uma versão fixada por manifesto, o Setup do Foundry aceita uma manifest URL. O manifesto da versão indicada é:
Após instalar, reinicie o mundo de teste e faça rolagens de atributo, perícia e habilidade — inclusive pelos fluxos do Epic Roll(s). Confirme no chat que a fórmula e o total continuam sendo d20; não decida pelo modelo 3D sozinho. Se persistir, desative temporariamente apenas o Dice So Nice nesse mundo para separar falha de renderização de uma incompatibilidade de automação. Não desatualize módulos de produção sem backup e sem teste reproduzível.
Comportamento de Damage (fast) no Midi-QOL
Relato local (2026-09-02): em uma Activity de ataque Rend, após um acerto já resolvido, o botão Damage (fast) do card de chat reiniciou a sequência pelo ataque antes de produzir um novo dano. O relato não confirma que seja a configuração desejada nem identifica a versão específica do Midi-QOL envolvida.
Confirmado (fonte do mantenedor): há registro de caso em que o dano não pôde ser rolado sem rolar antes o ataque quando a automação de rolagens estava habilitada. Portanto, trate o comportamento do card como dependente da combinação de versão do Foundry, D&D5e, Midi-QOL, Activity do item e configurações de automação — não como uma função estável garantida pelo rótulo fast.
Procedimento de teste antes de alterar a mesa de produção:
Em uma cópia do mundo, registre as versões de Foundry, D&D5e e Midi-QOL e exporte/registre as configurações do módulo.
Com um ator de teste, faça um ataque que acerte e, no card resultante, acione Damage (fast); registre se o d20 é rolado novamente e se o dano é aplicado.
Repita com a Activity diretamente pela ficha e com os módulos de automação não essenciais desativados, um por vez. Isso separa o fluxo do sistema D&D5e de interferência de módulo/configuração.
Só aplique uma mudança de configuração à produção depois de reproduzir o comportamento esperado no mundo de teste. Não use a própria sessão como ambiente de diagnóstico.
Procedimento para atualizações
Faça backup do User Data e teste primeiro numa cópia do mundo.
No Setup, atualize cada módulo que seja dependência de automação antes de elevar a versão do D&D5e.
Leia compatibility no module.json e as relações/dependências declaradas; os limites do manifesto são a referência operacional, não a aparência de funcionamento num mundo existente.
Abra cada mundo de teste com os módulos essenciais; verifique console, fichas, Active Effects, itens e fluxos de combate antes de atualizar a mesa de produção.
Para Foundry V14, use o Preview Compatibility no Setup e só prossiga após validar sistema, módulos essenciais e dados de mundo no ambiente de teste. Uma geração nova não deve ser atualizada diretamente a partir da instalação de produção.
Origem, licença e versões de pacotes
Diretriz operacional (registrada em 2026-10-09): para módulos gratuitos, usar o repositório/instalador do Foundry ou a URL de manifesto publicada pelo autor. Para conteúdo premium ou licenciado, atualizar exclusivamente pelo instalador associado à compra e à conta autorizada. Não usar cópias redistribuídas por canais não oficiais como fonte de atualização.
O module.json instalado é evidência técnica, não prova de licença. Antes de instalar ou atualizar, registrar a origem autorizada, conferir id, version, compatibility, relationships e a URL de manifesto, e manter backup do User Data. O Foundry recomenda os métodos de instalador ou manifesto em vez da cópia manual; o gerenciador também compara o manifesto remoto com a versão instalada para detectar atualizações.
Não registrar nesta nota versões de módulos obtidas em consultas pontuais: versões e compatibilidade mudam. Reconsultar a fonte autorizada e testar no mundo de cópia antes de qualquer promoção à produção.
Inventário reportado de módulos v13 → v14 (2026-10-12)
Relato de auditoria local; não reinspecionado nesta curadoria: a comparação entre foundry-data/v13/Data/modules e foundry-data/v14/Data/modules no host Windows declarou 293 módulos na v13 e 102 na v14. Desses, 78 estavam nos dois ambientes; 24 existiam apenas na v14 e 215 módulos da v13 não apareciam na v14. Esses totais descrevem o estado observado naquele momento, não uma lista automática de instalações necessárias.
O relato aponta uma regressão a conferir antes de habilitar mundos Daggerheart na v14: a v13 teria usado o satélite pessoal daggerheart-quickrules v2.0.0, integrado ao quickwiki-core, enquanto a v14 conteria o módulo upstream daggerheart-quickrules v0.2.6. Não substituir um pelo outro por nome: inspecionar id, autor, versão, manifesto e dependências, e testar o registro no core em uma cópia de mundo.
Também foi relatada coexistência de pf2e-automations-patreon v2.4.9 (legado v12) e patreon-v3 v3.2.23 na v14. Não remover o pacote legado diretamente na produção: fazer backup, identificar quais mundos o referenciam e validar o sucessor no ambiente de teste antes de desabilitar ou excluir qualquer diretório.
A auditoria classificou alguns módulos presentes como sem verificação formal declarada para v14, incluindo permission_viewer, nimble-quickrules, breaktime, hover-distance, epic-rolls-5e, notelicker, alien-mu-th-ur, boss-loot-adventures-premium e pacotes PF2e de Adventure Path/tokens. Ela também marcou mage-hand-press-valdas-spire-of-secrets e pf2e-tokens-bestiaries como especialmente defasados. Essas classificações não demonstram incompatibilidade: conferir o manifesto e a fonte do mantenedor na data da mudança, depois abrir uma cópia de cada mundo afetado e exercitar os fluxos dependentes.
O fluxo obrigatório continua sendo backup do User Data, leitura de compatibility e relationships dos manifestos, atualização a partir da fonte autorizada e validação por mundo de teste antes de promover uma alteração para mesas em produção.
Cópia não destrutiva de worlds v13 → v14 (2026-10-13)
Relato operacional no host Windows b450m; não reinspecionado nesta curadoria: o evento de transferência declarou a cópia de 45 worlds válidos da instalação v13 para a v14. A origem foi mantida somente para leitura: nenhum world foi movido, renomeado ou apagado, e nenhuma migração de schema ou teste de compatibilidade foi executado automaticamente.
O relato declara verificação pós-cópia de cada world por presença de world.json, contagem de arquivos e tamanho total, com zero falhas. Worlds que já existiam na v14 — cricible-ember, dnd-ember e test — teriam sido preservados sem colisão ou sobrescrita. Na origem, um README.txt de raiz foi ignorado, assim como o diretório vazio almas-perdidas e sss, que não continha world.json.
Decisão operacional registrada: a cópia de arquivos não equivale a aceite de migração. O DM deve abrir e migrar cada world manualmente pela interface da v14, primeiro em ambiente de teste, seguindo a verificação de sistema e módulos já descrita nesta nota. Não promover um world para uso em mesa apenas com base neste relatório de cópia.
Fonte local: evento 88f0aae4548d4c59b0b34484, lote batch-4a2ebc323d5a44d09f5d890c93520de5, consultado em 2026-10-13. Relata execução e verificações no host citado; arquivos de origem e destino não foram acessíveis nesta curadoria.
Área de teste v14 sincronizada por Syncthing (2026-10-13)
Relato operacional; não reinspecionado nesta curadoria: após validar os worlds no host Windows, foi configurada uma pasta Syncthing distinta para levar o User Data da v14 à VM: C:\Users\Yanbd\foundry-data\v14 → /home/ubuntu/foundry-data-v14, sob o ID foundry-data-v14 e rótulo Foundry Data V14. O relatório declara que a sincronização inicial criou/populou Data/worlds, Data/systems, Data/modules, Config e Logs no destino.
Decisão operacional: a área v14 é isolada da produção v13; não apontar o serviço de produção, nem o link ~/Data, para /home/ubuntu/foundry-data-v14. Usar esse caminho somente ao instalar/executar uma instância de teste separada, com porta, processo e cópia de dados explicitamente distintos. A existência da pasta sincronizada não valida os worlds nem autoriza sua promoção para sessão.
Fonte local: evento 399ad3411de49def1cf152cf, lote batch-17ec995b19664bcdb08348878cefb205, consultado em 2026-10-14. O lote contém o relato da configuração; o estado atual do Syncthing e do diretório de destino não foram verificados diretamente nesta curadoria.
Incidente de migração: ItemGrant com UUID relativo no world Sombras de Merritt (2026-10-13)
Relato de diagnóstico no host Windows; não reinspecionado nesta curadoria: depois da migração do world sombras-de-merritt para Foundry VTT v14, fichas de personagens apresentaram perda aparente de Raça, Classe, Subclasse e Antecedente na interface. O relato afirma que os documentos continuavam presentes nos bancos de dados da v13 e da v14; portanto, não conclui perda física de dados.
Escopo observado no censo relatado: o evento afirma que os 755 NPCs e o único veículo não apresentaram o sintoma. Entre 13 fichas do tipo personagem, 11 tinham a estrutura de Raça/Classe/Subclasse/Antecedente investigada. O mesmo evento declara 765 atores no total, mas as categorias informadas somam 769; por isso, o total não é registrado como confirmado. O evento atribui a diferença ao uso de Advancement/ItemGrant nesses itens de progressão das fichas de personagens, em vez de tratá-la como imunidade geral de NPCs a futuras migrações. O censo não substitui testes por world e por versão.
O log de cliente teria registrado falhas ao inicializar itens embedded com a validação ItemGrantConfigurationData: uuid: must not be a relative document UUID. A hipótese operacional relatada é incompatibilidade entre dados legados de Advancement/ItemGrant, que referenciam itens concedidos por UUID relativo iniciado por ponto (por exemplo, .abc123), e a validação aplicada pelo D&D5e 6.0.6 no ambiente v14. Quando a inicialização falha, o item afetado não é carregado na memória do cliente, o que explica a ficha incompleta sem demonstrar exclusão do registro no disco.
Procedimento obrigatório antes de migrar os demais worlds:
Manter a cópia v13 e criar uma cópia independente do world para teste; não usar a cópia de produção como alvo de migração.
Antes de abrir o world na v14, registrar versões de Foundry, D&D5e e módulos; conferir especialmente dados de Advancement/ItemGrant em raça, classe, subclasse e antecedente.
Migrar somente a cópia e abrir as fichas de todos os personagens. Verificar visualmente os quatro tipos de item, atributos, PV, magias, recursos e console do navegador.
Se surgir a mensagem de UUID relativo, interromper a promoção. Preservar o log e reparar os UUIDs somente na cópia, com backup adicional e conferência dos documentos antes e depois.
Só aceitar o world para mesa após uma verificação funcional das fichas e dos fluxos de jogo; o fato de o banco continuar contendo documentos não é validação da interface nem da mecânica.
Limite de evidência: a versão, o mecanismo de validação e a contagem de ocorrências pertencem ao relato e ao log daquele incidente; não generalizar para todo world, sistema ou versão futura sem reproduzir o teste no ambiente concreto.
Fontes locais: evento 76cec74de297df84e1a78f0b, lote batch-5486218a50b0441487aece9aac1bf4d1, consultado em 2026-10-14, contém o diagnóstico e a transcrição parcial dos erros de cliente. Evento 5cba85d2dce17b336616033c, lote batch-46e2b41923834c1099d35db3f8bba6f1, consultado em 2026-10-14, contém o censo de escopo relatado. Arquivos de log e bancos não foram relidos nesta curadoria.
Correção reportada e alcance preventivo (2026-10-14)
Relato de execução no host Foundry; não reinspecionado nesta curadoria: um evento posterior declara que a cópia v14 de sombras-de-merritt recebeu normalização dos UUIDs relativos em Advancement/ItemGrant: 28 itens de sete fichas, com 113 referências alteradas de uma forma relativa iniciada por ponto para a forma Item.<id>. O relato também afirma preservação dos vínculos locais das features e criação de backup prévio dos dados de atores. Estes números e a equivalência funcional dependem da conferência dos bancos e das fichas no ambiente de teste; a presente curadoria não teve acesso a eles.
O mesmo relato declara uma varredura preventiva em outros worlds D&D5e copiados para v14, encontrando o padrão em mais 21 worlds e aplicando backup e normalização antes da abertura. Isso é registro de escopo reportado, não evidência de que todos os worlds estejam prontos para produção. Cada world ainda precisa ser aberto como cópia de teste e ter fichas, console e fluxos de jogo exercitados conforme o procedimento acima.
Em sombras-de-merritt, o relato também diz que calendaria foi desativado em core.moduleConfiguration após um erro de carregamento atribuído à ausência da global ATLAS no core v14. Não trate isto como incompatibilidade geral confirmada do módulo: registrar a versão exata, reproduzir em uma cópia do world e consultar o manifesto/fonte do mantenedor antes de reativá-lo ou alterar outros worlds.
Fonte local: evento 54d49e907456fdc415e65368, lote batch-b022d15bb1ee4eb09fc2856eb3adf877, consultado em 2026-10-14. Contém o relatório de correção; não inclui releitura independente dos arquivos alterados nem teste de interface nesta curadoria.
Diagnóstico complementar: UUID de documento embedded (2026-10-13)
Relato de diagnóstico no host Foundry; não reinspecionado nesta curadoria: após a normalização dos UUIDs relativos, algumas fichas ainda teriam perdido Classe e Subclasse na interface. O evento atribui o sintoma a referências de Advancement/ItemGrant no formato Actor.<actorId>.Item.<itemId>. Segundo o relato, o campo DocumentUUIDField do D&D5e 6.0.6 aceita somente referências a documentos de tipo Item não embedded; por isso, essa forma seria rejeitada na inicialização e o item de classe não seria carregado na memória. A subclasse dependente então ficaria sem a classe pai ativa.
O relatório declara que havia 13 referências desse tipo restantes e propõe convertê-las para Item.<itemId>. Isso não é uma regra segura para aplicar indistintamente: antes de qualquer alteração, confirmar que cada itemId é resolvível como Item de mundo ou compêndio e preservar um backup verificável do banco de atores. A conversão deve ser feita exclusivamente em uma cópia de teste, seguida de abertura do world, inspeção visual de cada ficha afetada e conferência do console. A presente curadoria não recebeu confirmação de que a alteração foi aplicada nem de que as fichas foram validadas após a abertura.
Contexto externo confirmado: a página oficial do pacote D&D5e lista a versão 6.0.6 como compatível com Foundry VTT 14 e a release oficial a descreve como um patch da linha 6.0; a existência da versão não confirma o diagnóstico ou a alteração local.
Fontes: evento bc314968a7efa310e2f7fc1f, lote batch-15a5c3e0e23348b68cf2427b014d9846, consultado em 2026-10-14 (relato local, sem acesso ao banco ou à interface); Foundry VTT — Dungeons & Dragons Fifth Edition e foundryvtt/dnd5e — release 6.0.6, consultados em 2026-10-14.
Relato de execução e auditoria no host Foundry; não reinspecionado nesta curadoria: o evento posterior declara que as 13 referências restantes no formato Actor.<actorId>.Item.<itemId> foram convertidas para Item.<itemId> no banco de atores de sombras-de-merritt. O escopo informado foi: dois vínculos da classe/subclasse de Askel (Barbarian e Path of the World Tree), três de Caltash (Cleric e Twilight Domain), um de Kai (Druid) e cinco de QuebraNozes (Battle Master).
O mesmo relato informa uma auditoria pós-alteração de 3.970 itens com Advancement, sem UUID relativo iniciado por ponto e sem UUID embedded iniciado por Actor.. Essa declaração substitui o estado pendente registrado acima, mas não constitui validação independente do banco, nem do carregamento das fichas na interface. A abertura do world, a inspeção das fichas afetadas e a conferência do console ainda são necessárias antes de tratá-lo como aceito para mesa.
Como prevenção, o relatório também declara normalização do mesmo padrão em heroes-of-thylea (2 itens), heroes-of-thylea-friday (5), crown-of-the-oathbreaker (7), the-crooked-moon-2014 (8), chains-of-asmodeus (1) e backup (2). Esses worlds exigem a mesma validação em cópias de teste; o registro não autoriza iniciar ou promover nenhum deles sem teste funcional.
Fonte local: evento 747c33dda140d0b5b872c011, lote batch-9d6c228c834b4be98619f37e721f2ca7, consultado em 2026-10-14. O lote contém somente o relato da execução e da auditoria; os arquivos de banco e a interface do Foundry não foram acessíveis nesta curadoria.
Auditoria reportada: conteúdo de world e mídia ausente (2026-10-13)
Relato de auditoria no host Windows; não reinspecionado nesta curadoria: a comparação inicial entre as cópias v13 e v14 de um world declarou a mesma contagem de 765 Actors e 142 Scenes. Também declarou preservação de 9 RollTables, 9 Macros e 1 Playlist. Para Journals, o relatório registrou 67 entradas na v13 e 93 na v14, atribuindo a diferença à expansão esperada de páginas na migração; a contagem maior não deve, sozinha, ser tratada como confirmação de equivalência de conteúdo.
O relatório separa os dados de world das mídias: os documentos e suas referências teriam sido preservados, mas imagens podiam retornar 404 porque a transferência inicial se limitou a Data/worlds/, sem os assets físicos normalmente servidos a partir de Data/images/. Portanto, uma auditoria de Actors, Scenes e Journals não valida backgrounds, tiles, portraits, tokens ou handouts: além de comparar os bancos, conferir a presença das mídias no destino e abrir cenas representativas no ambiente de teste.
Atualização reportada — espelhamento de mídia e auditoria integral: um relato posterior declara cópia somente de arquivos ausentes da v13 para v14, sem sobrescrever o destino. Após a operação, foram informadas as seguintes paridades de arquivo e tamanho: Data/images (5.538 arquivos; 5.059.736.176 bytes), Data/origin-vault (325; 55.573.569 bytes) e Data/assets (207.567; 12.511.199.509 bytes). Também foram declarados presentes dmyan.jpg e transparent.png na raiz de dados. O evento intermediário informa 25.430 arquivos copiados, 182.137 preservados e zero falhas/mismatches; esses números pertencem ao relatório de execução e não foram repetidos nesta curadoria.
Auditoria de worlds reportada: a comparação de chaves LevelDB teria alcançado 45 worlds migrados. Entre eles, 42 foram declarados acessíveis, com leitura integral sem erro de decodificação e sem divergência de chaves para Actors (incluindo itens embedded), Scenes e subdocumentos, Journals e páginas, Items, RollTables, Playlists, Macros, Cards, Folders e Users. Os worlds cricible-ember, dnd-ember e test já existentes na v14 foram preservados intencionalmente como adicionais; não entram na equivalência com a origem.
Exceção reportada — crown-of-the-oathbreaker: foram identificados na v13, mas não na v14, 10 subdocumentos de Scene (6 lights e 4 notes), 1 JournalEntry e 6 páginas relacionadas à “Expansão Cinemática e Cartográfica de Onadbyr”. O próprio relatório atribui a diferença a conteúdo customizado criado ou modificado depois da cópia inicial, a partir de timestamps, e não o tratou como corrupção. Essa atribuição é uma inferência operacional do evento; antes de uma nova sincronização, comparar os documentos individualmente e preservar backup da cópia v14.
Procedimento de aceite: manter a origem v13 intacta; validar primeiro a cópia v14. Para cada world candidato, testar fichas, cenas com walls/lights/tokens, Journals e URLs de mídia carregadas pelo navegador. Registrar separadamente qualquer 404 como falha de cópia/sincronização de asset, sem concluir perda de documento antes de conferir o banco de dados.
Fontes locais: evento 16b22cfcd09c493746daf1a5, lote batch-feb17390482d4462bf170c2279465bbe, consultado em 2026-10-14; eventos 28422fa71afdecfcccb86cc0 e e62f475b3990eefea126cede, lote batch-f18f4fba9bec4ba78c58067f388c2ac3, consultado em 2026-10-14. Os arquivos, bancos e respostas HTTP do host não foram acessíveis nesta curadoria.
Fontes
Evidência local: auditoria da instalação Foundry VTT v13.351, 2026-08-29.
Foundry Virtual Tabletop — Package Management (consultado em 2026-10-09).
Foundry Virtual Tabletop — Module Management (consultado em 2026-09-03).
Capacidade Always Free do OCI Ampere A1
Confirmado (consulta em 2026-09-19): para VM.Standard.A1.Flex, a documentação atual da Oracle em português informa franquia Always Free de 3.000 OCPU-horas e 18.000 GB-horas mensais, equivalente a uma instância contínua de até 4 OCPUs e 24 GB de memória. Os recursos podem ser distribuídos entre instâncias; o consumo é agregado na tenancy.
A cota Always Free de bloco é 200 GB. O volume de boot mínimo por instância é 47 GB; portanto, o armazenamento também deve ser conferido antes de dividir a capacidade em múltiplas VMs.
Cuidado operacional — documentação divergente: a página de Recursos Always Free descreve 4 OCPUs/24 GB para tenancies Always Free, mas a página geral do Free Tier ainda alerta que, após o fim de uma avaliação gratuita sem upgrade, a tenancy deve ficar em 2 OCPUs/12 GB para preservar instâncias Arm. Não assumir que Pay As You Go é pré-requisito, nem que a cota de 4 OCPUs se aplica à tenancy concreta sem confirmar o status e os limites exibidos no Console. Uma conta paga é necessária para usar recursos que excedam a franquia; verificar também o Cost Estimator e a lista de preços da região antes de qualquer redimensionamento.
Aplicação ao Foundry: a forma é flexível e suporta redimensionamento de OCPUs e memória. Nenhum redimensionamento da VM de produção é implicado por este registro; validar capacidade disponível, consumo agregado e custo estimado no console da tenancy antes de alterar o shape.