Qual a melhor hospedagem para WordPress?

Em todos os fóruns de suporte, grupos de discussão e encontros técnicos, sempre surge esta questão: “qual a melhor hospedagem para WordPress?”, “que hospedagem eu escolho?”, “qual hospedagem vocês usam?”. O assunto então é discutido repetidas vezes, todo mundo tem sua opinião e é possível encontrar diversas referências toda a vez que se busca algo.

Resolvi então publicar as minhas recomendações, baseadas na minha experiência e no meu uso diário. Ou seja, eu utilizo todos os serviços que listo a seguir e eles foram minhas escolhas depois de alguns anos de estudo.

Observação: Os links incluídos neste artigo são patrocinados e me dão alguns centavos pela indicação. Alguns deles também oferecem gratuidades ou créditos de uso, conforme indicado.

Hospedagem compartilhada: SiteGround

SiteGround, serviço de hospedagem

Se ler em Inglês ou Espanhol não for problema, a SiteGround (https://www.siteground.com/go/marcoandrei-recomenda) é excelente. O serviço é de primeira linha, tem alto desempenho, o suporte é muito responsivo e oferece tudo necessário para um sítio WordPress, sendo de muito fácil administração. Ela inclusive é recomenda pela Yoast, WP Beginner e outros conhecidos no mundo WP.

Os planos são por espaço em disco tu podes hospedar quantos domínios quiseres, dentro deste limite. Os serviços oferecidos incluem também correio eletrônico, contas de acesso FTP para terceiros, bases de dados, certificado SSL Let’s Encrypt e cache da própria SiteGround, que dá uma agilidade sensível para teus sítios. O cuidado é que a utilização da maioria das coisas conta dentro do limite de armazenamento. Ou seja, tens que monitorar isso de perto.

Servidor gerenciado: Umbler

Falando de provedores nacionais, eu estou iniciando uma relação com a Umbler (https://www.umbler.com/br/seja-bem-vindo?a=j37nr07k), que está investindo em parcerias com agências, dando prioridade de atendimento. Clicando no endereço acima, tu recebes 7 dias de uso gratuito, independente do plano escolhido.

Há opções de hospedagem compartilhada (como a SiteGround) ou servidor próprio (como a DigitalOcean), mas eu uso os contêineres, que são como mini servidores VPS gerenciados pela Umbler, mas com diversas opções de configuração feitas no painel de controle. Tu podes ir aumentando (ou diminuindo) a capacidade do container de acordo com tua necessidade.

Eles também oferecem correio eletrônico com sistema próprio de webmail (bem legal, por sinal). Nas hospedagens, eles já oferecem uma conta gratuita de 1GB incluída no valor. Para mais contas e mais armazenamento, há mais opções (https://www.umbler.com/br/precos#emails?a=j37nr07k).

Servidor VPS não gerenciado: DigitalOcean

DigitalOcean

Se tens conhecimento de administração de servidores Linux e preferires montar teu próprio servidor, eu usaria a DigitalOcean (https://m.do.co/c/515618457caf). Eu tenho alguns servidores com eles, sem reclamações. O custo mínimo por mês é US$ 5 + US$ 1 se quiseres acionar o becape semanal, o que recomendo fortemente. O cupom no URL acima te dá US$ 100 de crédito para usar em 60 dias. Em um servidor de 1GB eu consigo hospedar 15 sítios WP com um acesso que não seja alto. Para sítios mais movimentados, eventualmente será necessário ter um servidor dedicado.

Painel administrativo para VPS: RunCloud

Para administrar os servidores da DigitalOcean, eu uso o que chamamos de Panel as a Service (PaaS), o painel de controle RunCloud (https://runcloud.io/r/z805M2aBekNd), que facilita o trabalho e instala o NGINX como servidor Web, que tem um desempenho melhor que o Apache. Há um plano gratuito para apenas UM servidor, com restrições, mas acho que vale a pena experimentar, porque já dá uma visão geral da interface e das facilidades do sistema. Se fores fazer um plano pago, o cupom no URL acima te dá 15 dias de uso gratuito em qualquer plano pago.

Alternativas gratuitas

Caso não queiras pagar pelo painel de controle, sugiro estudar o EasyEngine (https://easyengine.io/) ou o WordOps (https://wordops.net/), que é uma derivação dele. Para quem prefere fazer tudo pela linha de comando é uma mão na roda.

Os dois são scripts que são instalados no próprio servidor e ajudam a instalar a pilha LEMP (Nginx, MySQL e PHP no Linux) no teu servidor, além de facilitar a criação e manutenção de virtual hosts (espaço no servidor para cada domínio) e até mesmo instalar o próprio WordPress já com os plugins e configurações de cache.

Por fim, são programas de software livre que tem uma comunidade forte e bastante ativa. Nos fóruns de suporte, poderás tirar tuas dúvidas, mas a documentação dos dois é excelente.

E as hospedagens gratuitas? Vale a pena?

Essa é outra pergunta que sempre surge dentro desse tema. E a resposta direta para ela é: NÃO. Se tiveres oportunidade de testar, pode perdê-la.

Eu mesmo resolvi testar e tentei hospedar uma página básica e não consegui. Além do serviço ser LENTÍSSIMO para administrar (sim, lento MESMO), as hospedagens gratuitas ou te forçam a usar “construtores de sites” em que a estrutura já vem pronta, sem nenhuma personalização, ou limitam muitíssimo o espaço, pois são servidores compartilhados entre centenas (ou milhares) de clientes. Simplesmente não tem como usá-las para um projeto comercial sério.

Ah, sim: graças a “reputação” do Brasil, brasileiros estão banidos em alguns serviços por má fama em quebrar as regras do serviço ou por uso ilegal. Pois é.

E então? Gostaste das dicas? Ficaste com alguma dúvida? Tens um provedor preferido que gostarias de compartilhar? Deixa aí nos comentários, vamos trocar uma ideia!

SSH: Como forçar o uso de senha para autenticação?

Para desenvolvedores que têm conhecimento de infraestrutura e gostam de manter seu próprio servidor, usar o SSH para acessá-lo e fazer manutenções no WordPress e outras pastas é uma tarefa cotidiana. Normalmente o acesso se dá com a dupla usuário/senha, mas há casos, entretanto, em que a plataforma obriga ou já deixa o servidor pré-configurado para fazer o acesso somente por uma chave pública SSH.

Quando o acesso SSH por chave pública atrapalha

O acesso por chave pública é uma opção segura, mas pode ser um problema se tu não tens conhecimento dessa chave ou não estavas preparado para este tipo de acesso.

Nestes casos, ao se tentar acessar o servidor com o comando ssh usuario@servidor, recebemos aquele erro chato e sem muita explicação:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

Isso normalmente ocorre porque o SSH está tentando fazer a combinação de autenticação e a chave não está armazenada em tua máquina, simplesmente porque não existe.

Um exemplo comum são servidores criados nos serviços Lightsail ou EC2 da Amazon. Nestes serviços, os servidores não tem um usuário “root” e o acesso por padrão é via chave pública. Para melhorar, a documentação não é clara sobre este aspecto da configuração (até porque é quase toda em Inglês).

No caso da Umbler, é um pouco diferente. A documentação é melhor e o suporte é amistoso, o que já melhora 100%. Entretanto, para se fazer o acesso SSH é obrigatório fazer o envio da chave pública antes, não há a opção de acessar por senha.

Já na DigitalOcean, Vultr e outras, em geral é possível ter o acesso via chave pública, mas a autenticação padrão é por senha, o que pode ser menos seguro, mas é mais prático logo que se cria o servidor.

O que fazer?

O que fazer nestes casos? Na verdade é simples. Basta usar os parâmetros PreferredAuthentications (Autenticação Preferida) e PubkeyAuthentication (Autenticação por Chave Pública) para forçar o acesso por senha e dispensar a chave pública.

O comando ficaria assim:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no usuario@servidor

Ou seja, “Autenticação Preferida = senha” e “Autenticação por Chave Pública = não”.

Com esse comando, o SSH vai responder com:

usuario@servidor's password:

Daí é só entrar com a senha e pronto.

Tenha configurações SSH diferentes para cada servidor

Outra possibilidade interessante é guardar as configurações usadas para cada servidor que precisares fazer acesso.

Isso é feito por meio de um arquivo “config” que é gravado na pasta .ssh, a mesma onde ficam as chaves de acesso.

Criando um arquivo de configurações para o SSH

1) Acessa a pasta .ssh na tua pasta de usuário e cria um documento com o nome config e ajusta as permissões do arquivo para 600.

2) Edita o arquivo e cria seções iniciando sempre com este modelo

host <servidor ou padrão>

Por exemplo:

host *.gauderio.com
user gaudencio
port 9191
PubkeyAuthentication=no

Daí é só usar ssh indio-veio.gauderio.com que o SSH vai consultar o arquivo de configurações e aplicar as opções listadas acima.

Ainda há a chance de haver um arquivo de configuração padrão para todo o sistema. Neste caso, será necessário “enganar” o SSH, especificando uma configuração de mentirinha:

ssh -F /dev/null usuario@servidor

O parâmetro -F permite especificar um arquivo de configuração alternativo e a configuração padrão de sistema é ignorada.

Este artigo te ajudou? Ficaste com alguma dúvida sobre o SSH? Seguiste os passos e não funcionou? Deixa teu comentário aí embaixo para a gente ver juntos!