Ir diretamente para o conteúdo

Definições de cookies

Escolha que tipos de cookies permite. Pode alterar a sua escolha a qualquer momento em Definições de cookies, no fundo de cada página. Política de privacidade

Necessários

Sempre ativos

Necessários para iniciar sessão, manter o seu carrinho e memorizar as suas escolhas. Estão sempre ativos.

Que cookies?
  • weboke_sessie, weboke_klant, weboke_remember: a sua sessão e manter a sessão iniciada
  • weboke_basket: o seu carrinho
  • wkBtwIncl: mostrar preços com ou sem IVA
  • wok_cookies: a sua escolha de cookies, 12 meses

Mede que anúncio leva a uma visita ou encomenda, para não pagarmos por anúncios que não dão resultado.

Que cookies?
  • Google Ads via Google Tag Manager (_gcl_au, _gcl_aw), até 90 dias
  • OpenAI Ads, anúncios no ChatGPT
  • wok_aff: através de que parceiro chegou até nós (programa de afiliados), 60 dias

4,6

País e idioma

Cada país tem o seu próprio site, com os preços e o IVA desse país.

Ver

Colocar a sua aplicação do Lovable, do Bolt ou de outro construtor de IA no seu alojamento WebOké

Criou uma aplicação com o Lovable, o Bolt ou outro construtor de IA e pretende publicá-la no seu próprio domínio na WebOké? É possível. Neste artigo explicamos como obter o código do construtor de IA, como compilar e carregar a aplicação, e como o GitHub pode fazer isso automaticamente por si.

Verifique primeiro que tipo de aplicação tem. Disso depende se basta carregar ficheiros ou se a sua aplicação precisa de um servidor Node.js próprio.

1. Que tipo de aplicação tem?

Abra o ficheiro package.json no seu projeto. É aí que se vê o tipo de aplicação.

  • Uma aplicação estática (React com Vite). O package.json contém vite e nenhuma framework de servidor. Com npm run build cria uma pasta dist com ficheiros HTML, JavaScript e CSS normais. Esses ficheiros são carregados para public_html. Isto funciona em qualquer pacote de alojamento. Muitas aplicações do Bolt e as aplicações mais antigas do Lovable são construídas desta forma.
  • Uma aplicação com servidor próprio. Desde 13 de maio de 2026, o Lovable cria aplicações com TanStack Start: nesse caso, o package.json contém @tanstack/react-start. Uma aplicação deste tipo executa código de servidor e, por isso, não funciona como ficheiros soltos em public_html. Deve configurá-la como aplicação Node.js (consulte o ponto 6). O mesmo se aplica a outras aplicações com servidor próprio, como um backend Express.
  • Uma aplicação com Supabase ou Lovable Cloud como backend. A base de dados, o início de sessão e as funções permanecem no Supabase ou no Lovable. Na WebOké coloca apenas a parte visível (o front-end). Ao compilar, deve no entanto indicar o endereço e a chave pública do Supabase (consulte o ponto 5).

2. Obter o código do construtor de IA através do GitHub

O Lovable e o Bolt podem colocar o seu projeto num repositório GitHub próprio. As alterações passam a sincronizar nos dois sentidos: o que alterar no construtor de IA vai para o GitHub, e o que alterar no GitHub regressa ao construtor de IA.

No Lovable:

  1. Abra o seu projeto e aceda a Project settings > Git > GitHub.
  2. Clique em Add connection e conceda à aplicação Lovable acesso à sua conta GitHub.
  3. Em Accounts, clique em Connect. O Lovable cria um repositório privado e mantém-no atualizado.

Também é possível sem GitHub: com Download codebase em Project settings > Git pode transferir o código (com uma subscrição paga do Lovable).

No Bolt:

  1. Abra o seu projeto e clique no ícone do GitHub, no canto superior direito.
  2. Inicie sessão no GitHub, clique em Authorize e instale a aplicação GitHub do Bolt.
  3. Introduza um nome para o repositório e clique em Create repository. A partir daí, o Bolt trabalha no branch main.

3. Compilar e carregar uma aplicação estática

A aplicação é compilada no seu próprio computador. Para isso, precisa do Node.js, versão 22 (a versão atual do Vite exige, no mínimo, a 20.19 ou a 22.12).

  1. Obtenha o código: faça git clone do seu repositório ou extraia o ficheiro transferido.
  2. Abra um terminal na pasta do projeto e instale os pacotes com npm ci (ou npm install se não existir um package-lock.json).
  3. Compile a aplicação com npm run build. Passa a existir uma pasta dist com um index.html e uma pasta assets.
  4. Carregue o conteúdo de dist para domains/seudominio.pt/public_html, com um programa de FTP ou com o Gestor de Ficheiros do DirectAdmin. Não carregue, portanto, a própria pasta dist, nem o código-fonte ou node_modules.
  5. Coloque o ficheiro .htaccess abaixo em public_html.

Uma aplicação com várias páginas (um router) mostra no browser endereços como seudominio.pt/sobre-nos. Essas páginas não existem como ficheiro no servidor. Se atualizar uma dessas páginas ou abrir a ligação diretamente, recebe um erro 404. Com este ficheiro .htaccess, o servidor encaminha esses endereços para index.html e a aplicação apresenta a página correta:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^assets/ - [R=404,L]
RewriteRule ^ index.html [L]

Os ficheiros e pastas existentes são apresentados normalmente pelo servidor. Um ficheiro em falta em assets devolve um verdadeiro erro 404, o que facilita a deteção de erros. Tudo o resto é encaminhado para a aplicação.

Coloque o ficheiro .htaccess na pasta public do seu projeto. O Vite copia todo o conteúdo de public para dist em cada compilação, pelo que o ficheiro é sempre carregado também. Não vê o ficheiro no seu programa de FTP ou no Gestor de Ficheiros? Os ficheiros cujo nome começa por um ponto ficam por vezes ocultos; consulte Mostrar e editar ficheiros ocultos como .htaccess.

4. Colocar a aplicação numa subpasta

Pretende disponibilizar a aplicação não em seudominio.pt, mas em seudominio.pt/app? Nesse caso, a aplicação tem de saber isso já no momento da compilação. Caso contrário, o browser procura os ficheiros em /assets em vez de /app/assets e o ecrã fica em branco.

  1. Em vite.config.js (ou vite.config.ts), defina a opção base: '/app/'.
  2. Indique o mesmo caminho ao router. No React Router, isso faz-se com <BrowserRouter basename={import.meta.env.BASE_URL}>.
  3. Compile novamente e carregue o conteúdo de dist para public_html/app.
  4. Coloque em public_html/app/.htaccess o mesmo ficheiro indicado acima, com RewriteBase /app/.

5. Supabase, Lovable Cloud e outras definições (variáveis env)

As definições que começam por VITE_, como VITE_SUPABASE_URL e VITE_SUPABASE_PUBLISHABLE_KEY (em projetos mais antigos VITE_SUPABASE_ANON_KEY), são colocadas pelo Vite nos ficheiros JavaScript durante a compilação. Depois disso, já não é possível defini-las no servidor.

  • Encontra os valores no ficheiro .env do seu projeto. Copie os nomes exatamente como estão.
  • Se o ficheiro .env não existir no seu projeto, crie-o na pasta do projeto antes de executar npm run build. Com GitHub Actions, defina-os como secret (consulte o ponto 7).
  • Se alterou algum valor, compile e carregue a aplicação novamente.
Tudo o que começa por VITE_ pode ser lido por qualquer visitante. A chave pública (publishable ou anon key) do Supabase pode estar aí, pois foi concebida para esse fim; o Supabase protege os seus dados com regras de segurança (row level security). Nunca coloque a chave service_role nem qualquer outra chave secreta numa variável VITE_.

6. Uma aplicação com servidor próprio: como aplicação Node.js

Uma aplicação com código de servidor, como uma aplicação TanStack Start criada no Lovable, é configurada através de Setup Node.js App no DirectAdmin. Pode ler como funciona em Ativar o Node.js no DirectAdmin. Para uma aplicação TanStack Start, proceda da seguinte forma:

  1. Compile a aplicação no seu computador com NITRO_PRESET=node-server npm run build. Será criada uma pasta .output.
  2. Crie uma aplicação em Setup Node.js App, com Node.js 22 e uma pasta fora de public_html, por exemplo apps/myapp.
  3. Carregue a pasta .output para essa pasta.
  4. Na mesma pasta, crie um ficheiro start.cjs com esta única linha e indique start.cjs em Application startup file:
    import('./.output/server/index.mjs');
  5. Defina as definições de que o servidor necessita, como SUPABASE_URL e SUPABASE_PUBLISHABLE_KEY, em Environment variables.
  6. Clique em Restart. Faça-o também após cada novo carregamento.

O pequeno ficheiro start.cjs é necessário porque o servidor em .output é um módulo JavaScript moderno (.mjs) e o ambiente Node.js carrega o ficheiro de arranque da forma antiga. Se a aplicação devolver um erro 503, consulte o ficheiro stderr.log na pasta da sua aplicação.

7. Implementação automática com GitHub Actions

Com o GitHub Actions, o GitHub compila a sua app a cada alteração no branch main e coloca o resultado no seu pacote. Como o Lovable e o Bolt escrevem no GitHub, uma alteração feita no construtor de IA fica online ao fim de poucos minutos. A função Git do DirectAdmin não compila nada, apenas coloca ficheiros no servidor; por isso, para uma app Vite, o GitHub Actions é mais prático.

Nunca coloque palavras-passe nem chaves no seu repositório. Guarde-as como secret no GitHub:

  1. Abra o seu repositório no GitHub e aceda a Settings > Secrets and variables > Actions.
  2. Clique em New repository secret, introduza o nome e o valor e clique em Add secret. Faça isto para cada secret da variante que escolher.
  3. Crie no seu repositório o ficheiro .github/workflows/deploy.yml com um dos dois exemplos abaixo.
  4. Após a alteração seguinte, verifique no separador Actions se correu bem. Com Run workflow também pode iniciá-lo manualmente.

Variante A: através de FTPS (todos os pacotes de alojamento). Crie no DirectAdmin uma conta FTP separada para o GitHub, escolhendo em Root Directory a opção Domain (consulte Como funciona o FTP na WebOké?). Secrets: FTP_SERVER (o nome do servidor do seu pacote, como linux2023.webawere.nl, e não o seu nome de domínio), FTP_USERNAME (o nome completo, como github@seudominio.pt), FTP_PASSWORD e os valores VITE_ da sua app.

name: Build and deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
        env:
          VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}
          VITE_SUPABASE_PUBLISHABLE_KEY: ${{ secrets.VITE_SUPABASE_PUBLISHABLE_KEY }}
      - uses: SamKirkland/FTP-Deploy-Action@v4.4.0
        with:
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          protocol: ftps
          port: 21
          local-dir: ./dist/
          server-dir: public_html/

Variante B: através de SSH com rsync (pacotes com SSH). O SSH está incluído no Power Webhost Three e Four, no AI Wordpress Three e no Power Reseller, na porta 1967 e apenas com chave (consulte Acesso SSH e o Terminal no DirectAdmin).

  1. Crie no seu computador uma chave separada para o GitHub, sem palavra-passe: ssh-keygen -t ed25519 -f github-deploy -N "".
  2. Cole o conteúdo de github-deploy.pub no DirectAdmin em SSH Keys > PASTE KEY.
  3. Coloque o conteúdo de github-deploy (a chave privada) no secret SSH_PRIVATE_KEY. Em seguida, elimine o ficheiro do seu computador.
  4. Execute ssh-keyscan -p 1967 linux2023.webawere.nl e coloque o resultado no secret SSH_KNOWN_HOSTS. Assim, o GitHub verifica que se liga realmente ao seu servidor.
  5. Adicione também como secret SSH_HOST (o nome do servidor), SSH_USER (o seu nome de utilizador do DA), DOMEIN (como seudominio.pt) e os valores VITE_.
name: Build and deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
        env:
          VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}
          VITE_SUPABASE_PUBLISHABLE_KEY: ${{ secrets.VITE_SUPABASE_PUBLISHABLE_KEY }}
      - name: Deploy
        env:
          SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}
          SSH_KNOWN_HOSTS: ${{ secrets.SSH_KNOWN_HOSTS }}
          SSH_HOST: ${{ secrets.SSH_HOST }}
          SSH_USER: ${{ secrets.SSH_USER }}
          DOMEIN: ${{ secrets.DOMEIN }}
        run: |
          mkdir -p ~/.ssh
          printf '%s\n' "$SSH_KEY" > ~/.ssh/deploy_key
          chmod 600 ~/.ssh/deploy_key
          printf '%s\n' "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
          rsync -rlptz --delete --exclude=.well-known --exclude=cgi-bin \
            -e "ssh -p 1967 -i ~/.ssh/deploy_key" \
            dist/ "$SSH_USER@$SSH_HOST:domains/$DOMEIN/public_html/"
Com --delete, o rsync remove de public_html tudo o que não faz parte da sua app, exceto .well-known (necessário para o seu certificado SSL) e cgi-bin. Se existir mais alguma coisa em public_html, como um segundo site numa subpasta, remova --delete ou coloque a app numa subpasta própria.

Se não utilizar o Supabase, remova as linhas com VITE_SUPABASE ou substitua-as pelas variáveis VITE_ da sua própria app. Se o início de sessão falhar várias vezes, o servidor bloqueia temporariamente o endereço IP do GitHub. Nesse caso, verifique os seus secrets e inicie novamente o workflow.

8. Erros frequentes

  • A página inicial funciona, mas ao atualizar a página ou ao abrir uma ligação direta aparece um erro 404. O ficheiro .htaccess do ponto 3 está em falta ou encontra-se na pasta errada.
  • Um ecrã em branco. Abra as ferramentas de programador do seu browser (F12) e consulte o separador Consola ou Rede. Vê erros 404 em ficheiros dentro de /assets? Nesse caso, o caminho não está correto: carregou a própria pasta dist em vez do respetivo conteúdo, ou a aplicação encontra-se numa subpasta sem a base correta (ponto 4).
  • A aplicação carrega, mas o início de sessão ou os dados não funcionam, ou surge uma mensagem como supabaseUrl is required. As variáveis VITE_ não estavam disponíveis no momento da compilação. Defina-as no ficheiro .env ou como secret e volte a compilar.
  • A compilação falha com uma mensagem sobre a versão do Node.js. Utilize o Node.js 22, tanto no seu computador como no workflow (node-version: 22).
  • O comando npm ci falha. Não existe um ficheiro package-lock.json, por exemplo porque o projeto tem apenas um bun.lock. Execute uma vez npm install e adicione o novo package-lock.json ao seu repositório.
  • A compilação não contém nenhum index.html. Trata-se então de uma aplicação com servidor próprio, como o TanStack Start. Configure-a como aplicação Node.js (ponto 6).

Consulte também: Ligar com o FileZilla (FTP, FTPS e SFTP) e Chaves SSH e iniciar sessão com SSH.

Explicação detalhada com capturas de ecrã: Configurar uma aplicação Node.js no manual do DirectAdmin.

Este artigo foi útil?

← Voltar a Alojamento: geral

Um momento…

Configurar os seus domínios

Para cada domínio, defina os servidores de nomes, a ligação ao seu alojamento e quem fica como titular.

A carregar os seus domínios…