Samuel Arendt

WordPress no navegador remove o hosting da primeira experiência

A WordPress.org lançou o my.WordPress.net no começo de março. É um WordPress completo que roda inteiramente no navegador. Sem servidor. Sem plano de hosting. Sem domínio. Sem cadastro.

A tecnologia por trás é o WordPress Playground — WebAssembly rodando PHP e SQLite direto no browser. Isso já existia como demo técnica. A diferença agora é que virou um produto persistente. Você abre, cria, e seus dados ficam salvos no storage local do navegador. Volta no dia seguinte e o site está lá.

O site que você cria é privado por padrão. Não é acessível pela internet. Ninguém vê, a menos que você decida exportar ou publicar. E como roda localmente, um assistente de IA pode modificar plugins e temas no seu ambiente sem risco de afetar nada em produção.

Limitações existem. O storage começa em ~100MB — suficiente pra um blog pessoal, uma landing page, um protótipo. Não é pra rodar um e-commerce com 50 mil SKUs. Os dados vivem no browser específico daquele dispositivo. Se trocar de máquina, precisa exportar.

O que isso muda na prática: onboarding. Até agora, o primeiro contato com WordPress exigia pelo menos uma decisão de hosting. Pra quem quer testar um tema, validar uma ideia, ensinar WordPress pra alguém — essa barreira sumiu. É abrir o browser e começar.

Ainda não dá pra saber se isso muda algo no mercado de hosting WordPress ou se fica restrito a protótipos e uso pessoal. A recepção na comunidade está dividida — parte vê como democratização, parte como limitação demais pra levar a sério. Vale acompanhar como a WordPress.org evolui o storage e a sincronização entre dispositivos nos próximos meses.

A primeira hora sem escolher plano nem domínio

O five-minute install pedia PHP, banco, servidor e um nome. O my.WordPress.net pede um browser. Aluno, designer testando tema e time validando modelo de conteúdo chegam no editor sem a reunião de infra. A decisão de hosting sai do caminho da primeira sessão.

Playground já fazia demo que morria ao fechar a aba. Fellyph Cintra, no DevRel da Playground, marcou a diferença: esta instância persiste por padrão. Fecha o notebook, volta no dia seguinte, o site está no storage daquele browser.

O anúncio fala em workspace pessoal, privado, sem tráfego. Hosting continua na mesa quando existe URL pública, backup gerenciado, mais de um dispositivo ou alguém para colaborar. A primeira barreira cai; domínio, backup e colaboração pública seguem como decisão à parte.

100 MB, um browser e o hábito de exportar

O teto inicial de cerca de 100 MB cabe blog, landing, aula, CRM pessoal e reader RSS do catálogo de apps. Não cabe catálogo grande nem biblioteca de mídia. Os dados não sobem para um servidor da WordPress.org. Ficam no dispositivo. Trocar de máquina exige export. Limpar o perfil do browser pode apagar o site.

A documentação pede backup regular e avisa que a primeira abertura demora enquanto o WordPress baixa e inicializa. Se o workspace for de trabalho de verdade, o export periódico e o teste de reimport precisam existir fora daquele browser, no mesmo espírito de qualquer dado que não se pode perder.

Cada dispositivo é uma instalação. O WordPress no browser é um computador só. Quem precisa do mesmo conteúdo no notebook e no celular já encontrou o limite do desenho atual.

IA no site que o visitante não alcança

Como o ambiente é local e privado, um assistente pode alterar plugin e tema sem visitante no meio. O post da WordPress.org descreve o WordPress como base que a IA consulta e modifica. Para prototipar um bloco ou um plugin pequeno, o isolamento ajuda.

O isolamento também esconde dano. Agente que corrompe o site local leva o trabalho embora se não houver export. Trate a sessão de IA como laboratório com backup, ou use o reset e as instâncias temporárias que zeram no refresh. O rascunho único de um texto não deveria viver só ali.

O catálogo (CRM, reader, workspace de IA) instala com um clique e configura sozinho. Serve para mostrar o que WordPress faz quando não precisa ser um site público. Não serve como atalho para pular revisão de plugin em ambiente que um dia vai ser publicado.

Quando o protótipo pede URL e quando pode ficar no storage

A landing pergunta se você está pronto para ir além e aponta hosting dedicado para acessar de qualquer dispositivo, publicar ou convidar gente. Essa é a decisão operacional: o browser tira a primeira hora; a URL pública devolve domínio, backup, uptime e a pergunta de quem paga a conta.

Na comunidade, parte da recepção foi perguntar se isso já não era o Playground. A persistência por padrão importa para quem usa. Para um time de produto, a pergunta útil é outra: em qual momento o protótipo deixa de caber em 100 MB e num único browser.

Enquanto storage maior e sync entre dispositivos não existirem de forma robusta, my.WordPress.net é aprendizado, rascunho e software feito para pouca gente. Qualquer coisa que outra pessoa precise ver sem copiar um arquivo volta para o hosting, seja WordPress.com, seja um VPS.

Referências

#Arquitetura, #Estratégia, #Qualidade de Software