Minha aplicação funciona no computador. Como coloco no ar?

Sua aplicação já funciona, mas enviar um link para alguém parece uma tarefa completamente diferente. Surgem nomes como servidor, domínio, variável de ambiente e deploy, muitas vezes apresentados como se você já soubesse onde cada um entra.

Colocar no ar significa executar a aplicação em um ambiente acessível pela rede e cuidar do que ela precisa para continuar funcionando ali. Você pode aprender esse caminho por partes: entender a execução, separar a configuração, decidir onde guardar dados e só então publicar.

Vamos organizar essas decisões antes de escolher uma hospedagem. Mais adiante, você vai executar um pequeno servidor em Java 21 no próprio computador. Esse ensaio não exige conta de nuvem ou cartão e ajuda a reconhecer o que uma plataforma fará por você.

Entenda o que precisa continuar ligado

Servidor pode significar o programa que atende requisições ou a máquina onde ele roda. Um provedor pode administrar a máquina para você; mesmo assim, seu programa precisa iniciar e ouvir em um endereço e uma porta. Porta é o número usado para encaminhar uma conexão ao serviço correto.

Uma página estática já tem seus arquivos prontos para entrega. Uma API que registra reservas precisa executar código para cada operação e guardar dados. Por isso, escolher “hospedagem de site estático” não resolve automaticamente a necessidade de executar um backend.

Também separe construir de iniciar. O build prepara o projeto para execução. Em Java, vamos compilar o arquivo .java com javac e iniciar o resultado com java. Depois de iniciado, o processo precisa continuar ativo para atender novas requisições.

Faça um primeiro ensaio sem expor sua máquina

Crie uma pasta vazia e salve o código como Servidor.java. Você precisa do JDK 21, o conjunto que inclui compilador e ferramentas de execução. Confira java -version e javac -version; ambos devem indicar 21. O programa usa o módulo jdk.httpserver, já incluído no JDK, sem dependências externas.

Para acompanhar o código, você precisa reconhecer uma classe, o método main e uma condição if. Leia em três partes: primeiro a configuração; depois a função que atende cada requisição; por fim, start, que inicia o servidor. Os import dão acesso às classes do JDK. A expressão troca -> { ... } é uma função, chamada lambda, executada para cada pedido. O bloco try com o fluxo de saída fecha esse recurso ao terminar a resposta.

import com.sun.net.httpserver.HttpServer;
import java.net.InetSocketAddress;
import java.nio.charset.StandardCharsets;

public class Servidor {
    public static void main(String[] args) throws Exception {
        String host = System.getenv().getOrDefault("HOST", "127.0.0.1");
        int porta;
        try {
            porta = Integer.parseInt(System.getenv()
                .getOrDefault("PORT", "3000"));
        } catch (NumberFormatException erro) {
            throw new IllegalArgumentException("PORT deve ser inteira", erro);
        }
        if (porta < 1 || porta > 65535) {
            throw new IllegalArgumentException("PORT deve estar entre 1 e 65535");
        }

        var servidor = HttpServer.create(new InetSocketAddress(host, porta), 0);
        servidor.createContext("/", troca -> {
            boolean rota = troca.getRequestURI().getPath().equals("/saude");
            boolean get = troca.getRequestMethod().equals("GET");
            int status = !rota ? 404 : get ? 200 : 405;
            String corpo = status == 200 ? "{\"status\":\"ativo\"}"
                : status == 404 ? "{\"erro\":\"Rota nao encontrada\"}"
                : "{\"erro\":\"Metodo nao permitido\"}";
            byte[] bytes = corpo.getBytes(StandardCharsets.UTF_8);
            troca.getResponseHeaders().set("Content-Type", "application/json; charset=utf-8");
            troca.getResponseHeaders().set("Cache-Control", "no-store");
            if (status == 405) troca.getResponseHeaders().set("Allow", "GET");
            boolean head = troca.getRequestMethod().equals("HEAD");
            troca.sendResponseHeaders(status, head ? -1 : bytes.length);
            try (var saida = troca.getResponseBody()) {
                if (!head) saida.write(bytes);
            } finally {
                troca.close();
            }
            System.out.println("resposta status=" + status);
        });
        servidor.start();
        System.out.println("Servidor em http://" + host + ":" + porta);
    }
}

Defina explicitamente o endereço local e a porta antes de iniciar, para não herdar uma configuração diferente de outro projeto. No PowerShell do Windows:

$env:HOST = '127.0.0.1'
$env:PORT = '3000'
javac --release 21 --add-modules jdk.httpserver Servidor.java
java --add-modules jdk.httpserver Servidor

No Bash do Linux/macOS:

javac --release 21 --add-modules jdk.httpserver Servidor.java
HOST=127.0.0.1 PORT=3000 java --add-modules jdk.httpserver Servidor

Mantenha esse terminal aberto. Em outro terminal, execute curl.exe -i http://127.0.0.1:3000/saude no Windows, ou curl -i http://127.0.0.1:3000/saude no Linux/macOS. Você deve ver status 200 e o JSON {"status":"ativo"}. Troque o caminho por /inexistente: o status deve ser 404. Na rota /saude, acrescente -X POST ao comando: o retorno será 405, com o cabeçalho Allow: GET.

127.0.0.1 aponta para a própria máquina e mantém este ensaio local. HOST e PORT são configurações lidas quando o processo inicia. A função registrada em createContext decide a resposta de cada requisição; a comparação exata do caminho evita tratar /saude/extra como a mesma rota. A documentação de HttpServer no JDK 21 explica esse mapeamento.

Encerre com Ctrl+C e tente consultar novamente. A conexão falha porque não há processo atendendo. Esse é um aprendizado importante para deploy: possuir o arquivo no servidor não significa que a aplicação esteja em execução.

O ensaio não contrata recursos; usa seu computador e sua conexão existentes. Não abra portas no roteador para transformá-lo em hospedagem pública. O programa também não implementa autenticação, reservas ou verificação de banco: 200 em /saude confirma apenas que esse processo respondeu.

Separe configuração de código e de segredo

Uma variável de ambiente é um valor fornecido ao processo quando ele inicia. A porta pode vir do provedor. O endereço do banco muda entre desenvolvimento e hospedagem. Uma senha precisa ficar fora do repositório e ser fornecida pelo mecanismo de segredos da plataforma.

Um erro frequente é manter localhost como endereço do banco ao publicar. Na máquina de hospedagem, esse nome aponta para ela mesma, não para o banco do seu computador. Use o endereço fornecido para a conexão da aplicação ao banco e confira as regras de rede e criptografia desse serviço.

Quando sua aplicação passar a guardar informações, planeje um banco persistente. Pense numa reserva de equipamento: ela precisa continuar existindo depois que o processo reinicia. A memória desaparece nesse reinício; arquivos num disco temporário também podem ser perdidos em um novo deploy. Confirme a garantia de persistência do serviço escolhido.

As migrações registram mudanças na estrutura do banco, como criar a tabela de reservas. Rode-as no ambiente correto e tenha um plano para mudanças incompatíveis. Backup só ajuda quando você sabe restaurá-lo; voltar o código não desfaz automaticamente uma alteração de dados.

Transforme o ensaio em um roteiro de publicação

Agora fica mais fácil entender o trabalho da hospedagem: preparar o ambiente, construir o projeto e iniciar o processo com sua configuração. No Render, o caminho documentado que vamos considerar para Java usa Docker. Um contêiner reúne o ambiente de execução e a aplicação; o arquivo Dockerfile descreve como preparar essa imagem.

Antes de criar qualquer serviço, confira a página de preços e o resumo de cobrança na sua conta. Serviço de aplicação, banco, armazenamento, tráfego e domínio podem ter cobranças separadas. Valores em moeda estrangeira também dependem da conversão e dos encargos da forma de pagamento. Não há orçamento mensal calculado neste artigo: ele depende das opções escolhidas. Se você não quer assumir custo agora, termine no ensaio local.

Numa pasta de exercício com apenas Servidor.java, acrescente este arquivo chamado Dockerfile, sem extensão. Ele usa a imagem oficial Eclipse Temurin, compila o programa e define seu comando de início. A instrução USER faz a aplicação executar com um identificador sem privilégios de administrador dentro do contêiner.

FROM eclipse-temurin:21-jdk-jammy
WORKDIR /app
COPY Servidor.java .
RUN javac --release 21 --add-modules jdk.httpserver Servidor.java
USER 10001:10001
ENV HOST=0.0.0.0 PORT=3000
CMD ["java", "--add-modules", "jdk.httpserver", "Servidor"]

Com Docker instalado e em execução, rode os comandos a seguir nessa pasta. O primeiro pode baixar a imagem Java. O segundo inicia um contêiner e publica sua porta somente no endereço local do seu computador:

docker build -t buildrun-java-ensaio .
docker run --rm -d --name buildrun-java-ensaio -p 127.0.0.1:3000:3000 buildrun-java-ensaio

Encerre o servidor iniciado anteriormente antes desse passo, para liberar a porta 3000. Repita as consultas HTTP e leia os registros com docker logs buildrun-java-ensaio. Ao terminar, execute docker stop buildrun-java-ensaio; --rm remove esse contêiner quando ele para. A imagem local permanece disponível. Esse teste usa seu computador, sem contratar hospedagem.

Para levar o mesmo pacote ao Render, envie os dois arquivos a um repositório de exercício sem segredos. Crie um serviço web, selecione esse repositório e a branch desejada, escolha Docker e aponte para o Dockerfile. Mantenha o comando de início definido por CMD. Confira plano, valores e configurações antes de confirmar a criação.

Na hospedagem, configure HOST=0.0.0.0 e respeite a porta fornecida pela plataforma. Esse endereço permite ouvir nas interfaces do ambiente; não é uma URL para o visitante. Configure /saude como verificação do processo e acompanhe os registros de build e início. A documentação de serviços web detalha porta e URL pública.

O roteiro remoto fica como próximo passo, sem contratação ou deploy realizado neste artigo. Executar o pacote localmente não comprova a configuração remota: confira a URL HTTPS fornecida pela plataforma e repita as mesmas consultas depois da publicação. A imagem base recebe atualizações; registre a versão ou o identificador exato utilizado se precisar reproduzir um build no futuro.

Use o endereço do provedor antes de comprar um domínio

Um domínio oferece um nome legível. O DNS relaciona esse nome aos destinos configurados. Ele não executa sua aplicação e não corrige um processo que falhou ao iniciar. A introdução da MDN a nomes de domínio ajuda a separar essas responsabilidades.

Primeiro valide a URL do provedor. Um domínio próprio é opcional nesse estágio e costuma exigir registro e renovação pagos. Se avançar, siga os registros DNS indicados pela hospedagem e confirme o certificado HTTPS. Não altere um domínio já usado por outro sistema como exercício.

Verifique o que aconteceu depois do deploy

Build concluído, processo iniciado e comportamento correto são três verificações diferentes. Guarde o identificador do commit publicado. Consulte a rota de saúde, provoque uma resposta esperada e leia os logs, registros dos acontecimentos da aplicação. O exemplo registra somente o status para evitar colocar entradas do visitante no log.

Na API completa, faça uma reserva com dados fictícios, reinicie o processo e consulte novamente. Ela deve continuar no banco. Verifique também um conflito: uma página inicial funcionando não prova que a regra de negócio está protegida.

Observe erros, tempo de resposta e disponibilidade. Se publicar uma versão defeituosa, interrompa a sequência de alterações e use o mecanismo documentado de retorno à versão anterior. Verifique se ela ainda é compatível com o banco. Depois de um experimento pago, remova os recursos dispensáveis e confira a cobrança; fechar o navegador não os desliga.

Se você conseguiu iniciar o servidor, consultar as respostas e observar o que acontece ao encerrá-lo, já compreende uma parte importante da publicação. O próximo passo é repetir esse comportamento em outro ambiente, conservando a capacidade de explicar como ele foi iniciado. Se ainda falta um projeto para esse percurso, veja o portfólio backend além do tutorial. Para aprofundar execução e operação, consulte a trilha de backend e DevOps a partir da dificuldade que apareceu no seu ensaio.

Fontes consultadas em 04/11/2026. O ensaio local não substitui avaliação de segurança, autorização, persistência e custos de uma aplicação pública.