Download the PHP package argws/laravel-updater without Composer

On this page you can find all versions of the php package argws/laravel-updater. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of argws/laravel-updater

Informations about the package laravel-updater

argws/laravel-updater

Pacote Composer para autoatualização segura, idempotente e reversível de aplicações Laravel, agora com camada de Updater Manager (painel administrativo, auth independente, branding white-label e API de disparo).

Compatibilidade

Instalação

Pré-requisito obrigatório: PDO SQLite

O updater usa SQLite para estado interno (runs, sessões e metadados).
Em qualquer ambiente (CLI/FPM/FrankenPHP), habilite a extensão pdo_sqlite.

Exemplo de verificação:

Se o comando não listar pdo_sqlite, habilite no php.ini:

Atualização do config após update do pacote

Publicação automática de config/views (equivalente ao --force)

A partir desta versão, o updater pode sincronizar automaticamente (em execução de console) os arquivos publicados de config e views para manter o pacote atualizado, com comportamento equivalente ao vendor:publish --force.

Controle por .env:

Se quiser desativar a sincronização automática, ajuste para false.

Por padrão, o vendor:publish não sobrescreve config/updater.php se ele já existir no seu projeto. Se uma nova versão do pacote trouxer chaves novas no config, você tem 2 opções:

Dica: se você personaliza config/updater.php, recomendo versionar esse arquivo no seu repositório.

Os assets do updater são sincronizados automaticamente para public/vendor/laravel-updater durante o boot do pacote. Assim, você não precisa rodar php artisan vendor:publish --tag=updater-assets --force a cada instalação/atualização.

Rotas principais

Variáveis de ambiente (principais)

Padrão recomendado de .env por cenário

Importante: após qualquer alteração no .env, execute php artisan config:clear.

1) Produção (recomendado)

Quando usar:

2) Homologação / teste manual pelo painel

Quando usar:

3) Compatibilidade de variáveis antigas de login

O updater aceita os dois formatos abaixo para rate limit do login UI:

Se ambos existirem, o formato novo (UPDATER_UI_RATE_LIMIT_*) tem prioridade.

.env do updater sem sobrescrever seu .env atual

Para reaproveitar o .env atual da aplicação (sem perder chaves já existentes), o pacote inclui:

E um comando de sincronização não destrutiva:

Perfis disponíveis em --profile:

Esse fluxo mantém o .env existente e só acrescenta parâmetros do updater que ainda não existem.

Seed pós-update (comportamento padrão)

Por padrão, após cada update o updater tenta executar somente:

Se a classe não existir na aplicação host, o updater apenas registra log e segue o pipeline.

As seeds padrão do sistema (DatabaseSeeder) não rodam por padrão. Para instalação inicial (zero), habilite explicitamente:

Ou via .env:

Também é possível trocar a classe da seed específica:

CI e release

Segurança

Usuário master + permissões por perfil

Defina no .env o usuário master que sempre terá acesso total, independente das permissões marcadas na UI:

No menu /_updater/users você pode definir permissões específicas de cada usuário (dashboard, updates, backups, logs, fontes, perfis, usuários, settings etc.).

Comandos Artisan

Notificação de nova atualização (tag/release)

Habilite no .env:

Agende no App\Console\Kernel da aplicação host:

Regra de fonte/perfil ativo

Você pode cadastrar várias fontes e perfis, mas apenas UMA fonte ativa e UM perfil ativo devem ficar selecionados por vez para evitar conflitos.

Guia rápido de uso de fontes de atualização

1) Cadastrar fonte

Na tela Fontes (/_updater/sources):

Você pode cadastrar várias fontes, mas apenas uma fica ativa por vez.

2) Editar e excluir fonte

Na listagem de fontes:

3) Testar conexão real

Na tela de fontes, use Testar conexão real da fonte. O teste executa git ls-remote para validar acesso e listar versões/tags remotas.

Guia de atualização (fluxo recomendado)

  1. Vá em Atualizações (/_updater/updates).
  2. Selecione o perfil e a fonte.
  3. Escolha o modo (merge, ff-only, tag, full update se habilitado).
  4. Mantenha Dry-run antes marcado (padrão).
  5. Clique em Simular (Dry-run).
  6. Na tela da execução, clique em Aprovar e executar e informe a senha de admin.

O backup FULL é obrigatório antes da atualização real via UI.

Notificações de atualização (opcional)

As notificações são opcionais e aceitam múltiplos destinatários:

Também é aceito ; como separador de e-mails.

Troubleshooting (erros mais comuns)

Erro: Falha ao aplicar atualização: O updater só pode ser executado via CLI.

Causa comum:

Como resolver:

  1. Atualize para a versão mais recente do pacote (esta versão já trata o fluxo UI com --allow-http).
  2. Confirme UPDATER_TRIGGER_DRIVER=sync (homologação) ou queue (produção).
  3. Rode:

Erro no composer install: "The HOME or COMPOSER_HOME environment variable must be set"

Isso acontece quando o updater roda em um ambiente sem variáveis de usuário (muito comum em cron, supervisor ou quando o PHP é executado com um usuário sem shell).

✅ A partir desta versão, o updater faz fallback automático:

Se você quiser forçar valores específicos (opcional), pode exportar antes de rodar o comando:

Página de manutenção (503) e Whitelabel

Durante uma atualização, o updater ativa o maintenance mode e exibe uma página 503 própria.

Default (sem .env)

Se você não configurar nada, o updater usa automaticamente a view padrão do pacote:

Whitelabel por painel (prioritário)

No painel /_updater/settings você pode configurar tudo pela UI:

Essas configurações salvas no painel têm prioridade em relação ao fallback de configuração do projeto.

Fallback por .env (opcional)

Se você preferir não usar upload no painel, também pode apontar logo/ícone por URL:

Se existir upload no painel, ele tem prioridade sobre as URLs do .env.

Na tela de configurações de branding, os campos indicam claramente o que é cada ativo: logo do painel, favicon do painel e logo da manutenção.

Controles manuais de manutenção

No dashboard há botões para habilitar/desabilitar manutenção imediatamente.

Critérios de segurança aplicados:

Além disso, o updater adiciona automaticamente exceção de manutenção para o prefixo configurado em UPDATER_UI_PREFIX (ex.: /_updater), para que o painel continue acessível durante a janela de manutenção.

Em versões de Laravel que não suportam php artisan down --except, o updater faz fallback automático sem --except para não quebrar o fluxo de update/manutenção.

No modo de atualização por tag, se a aplicação já estiver exatamente na tag alvo, o updater trata como execução válida (sem falso erro por revisão inalterada).

Atualização de arquivos publicados (config/views)

O Laravel não sobrescreve automaticamente arquivos publicados em config/ e resources/views/. Se você publicou config/updater.php ou views e quer atualizar para a versão mais recente do pacote (atenção: isso pode sobrescrever alterações), rode:

Erro: .git não é criado automaticamente

Checklist:

  1. UPDATER_GIT_AUTO_INIT=true
  2. UPDATER_GIT_REMOTE_URL preenchida e acessível
  3. UPDATER_GIT_PATH (se usado) aponta para a pasta correta e com permissão de escrita do usuário do PHP
  4. mantenha UPDATER_GIT_AUTO_DETECT_PATH=true para fallback automático quando o path estiver inválido
  5. git disponível no servidor (git --version)

Não aparecem atualizações disponíveis, mas o teste de conexão da fonte funciona

Isso normalmente indica divergência entre:

Valide:

  1. se UPDATER_GIT_PATH estiver configurado, a pasta deve ser o mesmo projeto conectado à fonte ativa;
  2. branch da fonte ativa bate com UPDATER_GIT_BRANCH;
  3. repositório local possui upstream correto (origin/main por exemplo);
  4. execute php artisan system:update:check para comparar com o status da UI.

Dica: por padrão, o updater não bloqueia o CHECK por working tree dirty (somente leitura). Se você quiser bloquear também, configure:

Solução para erro “Diretório atual não é um repositório git válido”

Se a aplicação não estiver na mesma pasta do updater, você pode configurar UPDATER_GIT_PATH com o diretório real do projeto Laravel versionado em Git. Se preferir, deixe UPDATER_GIT_PATH vazio e use UPDATER_GIT_AUTO_DETECT_PATH=true para detecção automática.

Exemplo:

Se você quer inicializar um diretório vazio automaticamente (cenário avançado), habilite:

Recomendado para produção: manter UPDATER_GIT_AUTO_INIT=false e usar um diretório já versionado.

Quando houver uma fonte ativa no painel, o updater usa automaticamente a URL/branch dessa fonte para bootstrap git (com UPDATER_GIT_AUTO_INIT=true), sem exigir UPDATER_GIT_REMOTE_URL manualmente.

Após alterar variáveis do updater em produção, execute também:

Migrador idempotente definitivo (updater:migrate)

Por que acontece o erro SQLSTATE[42S01] / errno 1050

Esse erro indica que a migration tentou criar uma tabela/view que já existe no banco (Base table or view already exists). Em ambientes reais isso ocorre por drift entre o banco e a tabela migrations (dump restore, merge manual, execução parcial/interrompida, ou banco adiantado).

Como a reconciliação evita a falha

O comando updater:migrate roda exatamente uma migration por vez e, quando a falha é classificada como ALREADY_EXISTS segura:

  1. confere se a migration já está na tabela migrations;
  2. se não estiver, reconcilia registrando a migration com batch correto;
  3. para constraints, valida via information_schema.TABLE_CONSTRAINTS/KEY_COLUMN_USAGE (MySQL/MariaDB);
  4. continua para a próxima migration.

No modo strict, qualquer dúvida de inferência/compatibilidade interrompe com erro orientando intervenção manual.

Configuração

Comandos

Retry/backoff de lock/deadlock

Para falhas LOCK_RETRYABLE (deadlock, lock wait timeout, metadata lock), o updater aplica retry com backoff progressivo (retry_sleep_base * 2^(tentativa-1) + (tentativa-1)), por exemplo base=3: 3s, 7s, 15s.

Quando usar modo strict

Use strict em ambientes novos/limpos, onde drift não é esperado. Em produção com histórico heterogêneo, mode=tolerant tende a reduzir falhas por objetos já existentes sem editar migrations antigas.

Nota sobre manutenção whitelabel

A view laravel-updater::maintenance agora possui fallback seguro: se o armazenamento de branding não estiver acessível no momento do artisan down --render, ela renderiza com valores de config (updater.app.* e updater.maintenance.*) em vez de falhar. Isso evita o cenário em que a aplicação não entra corretamente em manutenção por erro de renderização da view.

Caso idempotente adicional: DROP INDEX inexistente (MySQL errno 1091)

O migrador idempotente trata Can't DROP ... check that column/key exists (errno 1091) como drift idempotente no modo tolerante. Nesse caso, valida no information_schema.STATISTICS se o índice já está ausente, reconcilia a migration e segue o pipeline sem editar migrations antigas.

Correção de entrada em manutenção (REQUEST_URI no CLI)

Quando o host dispara erro Undefined array key "REQUEST_URI" durante artisan down --render, o updater agora injeta variáveis de servidor mínimas (REQUEST_URI, HTTP_HOST, SERVER_NAME, SERVER_PORT, HTTPS) no comando de manutenção. Com isso a aplicação volta a entrar em manutenção e exibir a view whitelabel do pacote.

Caso idempotente adicional: tabela inexistente em DROP (SQLSTATE 42S02 / errno 1146)

O classificador considera 42S02/1146 como idempotente somente quando o SQL indica operação de remoção segura (drop table, drop index, alter table ... drop, etc.). Se for consulta/uso normal (select, update, etc.), permanece NON_RETRYABLE para não mascarar erro real.

Correção definitiva para erro de ENCRYPTION_KEY no route:cache

Em alguns projetos, providers/helpers consultam ENCRYPTION_KEY via env()/getenv() durante comandos Artisan. Em execução não-interativa do updater, isso pode falhar mesmo com chave no .env.

O ShellRunner do pacote agora preserva o ambiente do processo e também faz fallback de leitura do .env (chaves ENCRYPTION_KEY e APP_KEY) para o comando filho. Isso evita quebra no cache_clear por falso negativo de chave ausente.

Tratamento de falha de route:cache por nome de rota duplicado

Se o host tiver rotas com nomes duplicados, o Laravel lança LogicException no route:cache. O updater agora pode seguir o pipeline sem abortar o update: registra warning e executa route:clear.

Controle por .env:

Healthcheck em localhost durante update

Para evitar falso negativo em ambientes onde APP_URL/healthcheck fica em localhost, o updater ignora healthcheck local por padrão.

Controle por .env:

Painel lateral técnico (novo)

A barra superior de versões/hash foi removida da interface.

Agora, o updater exibe o resumo técnico em um card responsivo no menu lateral (abaixo da navegação), incluindo:

Esse card foi desenhado para manter legibilidade em desktop e mobile sem poluição visual.

Upload em nuvem autocontido (Dropbox / Google Drive / S3 / MinIO)

O laravel-updater possui fluxo próprio de upload em nuvem para backups, sem depender de Storage::disk(...) da aplicação hospedeira.

Configuração na UI

Em /_updater/settings você encontra os campos específicos por provedor:

Também é possível definir:

Comportamento

All versions of laravel-updater with dependencies

PHP Build Version
Package Version
Requires php Version >=8.2
illuminate/support Version ^10.0|^11.0|^12.0
illuminate/console Version ^10.0|^11.0|^12.0
illuminate/filesystem Version ^10.0|^11.0|^12.0
illuminate/contracts Version ^10.0|^11.0|^12.0
monolog/monolog Version ^3.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package argws/laravel-updater contains the following files

Loading the files please wait ...