# Keeping a project current (https://lazyfrog.dev/docs/guide/keeping-a-project-current)

{/* Generated by scripts/generate-docs.ts from services/gateway/src/guide.md. Do not edit. */}

When you pick a project up after a while, or the user asks to keep it safe:
- `project_scan`: its security checks, and known vulnerabilities in the dependencies with the
  version that fixes each. Fix high ones first. Findings come grouped by rule and folder, and other
  people's code (WordPress core, plugins and default themes, installed packages, minified files)
  is left out and said so: don't edit it, keep WordPress and its plugins updated instead.
- Outdated dependencies: `exec` `uv tree --outdated` or `pnpm outdated`. Take patch and minor
  releases a few at a time, run the tests, then `deploy preflight` and publish; `deploy rollback`
  if anything breaks. New versions wait a week before they install here; a security fix younger
  than that can be taken early for that one package (`project_scan`'s fix says how), and the
  exemption taken out again afterwards.
- Restart the services after a dependency change (`service restart`).
- The project's template may have moved on since it was made (`project get` says so). Nothing
  changes by itself: compare what's new (README-for-AI.md, services.json, the template's own
  files) and bring over what fits, as ordinary changes.
- A published site keeps the platform version it was built on: publishing again picks up the
  platform's own improvements (the preview gets them when it next wakes). `project get` says when
  a newer one is there, and the owner sees it on the project's Overview: check the preview, then
  tell the user that publishing brings it to the live site; it's their call when.