Git records changes to project files, but it does not determine how those files become a working website. A Hugo project generates static output. A Django project needs a Python application runtime. A PHP application on a LAMP stack depends on its web server, PHP execution environment, and any database-backed behavior. The same successful push can therefore precede very different deployment tasks.
Choose a release process by tracing what happens after checkout. Identify the build step, the files served to visitors, the process executing application code, and the data that must survive releases. The Git hosting guide provides the broader hosting vocabulary; here the focus is matching the workflow to the stack.
Use four questions to describe the application
First, what is the source of truth? That may be Markdown and templates, Python modules and migrations, or PHP code with dependency definitions. Second, what must a build produce? The answer could be an entire static site or only stylesheets and scripts used by a running application.
Third, what runs when a visitor requests a page? A static file server and an application process have different operational requirements. Fourth, what changes after deployment? Uploads, database records, queued work, and user sessions may continue evolving while the code remains at the same commit.
Write these answers before choosing a deployment integration. A convenient button is useful only if its behavior matches the application. It should be clear which step installs dependencies, which step changes live data, and which step makes the new release visible.
Hugo: publish the generated website
A Hugo repository typically contains the content, templates, configuration, and other inputs used to generate a website. The build produces deployable static files, commonly in the public directory. Production hosting serves that output; visitors do not need the Hugo development server to render each page.
Record the Hugo version and any additional build dependencies required by the project. Build from a clean checkout with the intended production configuration. Confirm the base URL, navigation paths, generated feeds, and asset references in the output before uploading it.
Choose whether the hosting platform builds from source or receives a prepared artifact. Both approaches need a reproducible build description. If a separate deployment branch holds generated output, label that purpose clearly so authors do not edit generated HTML and expect those edits to survive regeneration.
A useful release package contains the generated site and an identifier for its source commit. Keep the previous verified package available for rollback. The static website deployment guide explains how to promote those artifacts and verify the resulting pages.
Django: release an application and its assets
Django needs more than a directory of static HTML. A deployment must install the appropriate Python dependencies, load production settings, connect required services, and run the application through a suitable WSGI or ASGI server. The development runserver command is not the production server.
The official Django deployment checklist covers production settings and checks, including protecting secrets and disabling debug output. Consult the documentation matching your installed version when applying those controls to your environment.
Keep the source of static assets distinct from the collected assets served in production. Django's collectstatic workflow gathers configured static files for delivery. User-uploaded media is separate, persistent application data; a new code release should not overwrite it.
Commit migrations with the application change they support. Review the migration plan before release, particularly when it alters existing data or requires a compatibility transition. Coordinate application process updates with the database change so the old and new code do not make conflicting assumptions while requests are still arriving.
LAMP: define the actual PHP application
LAMP describes a Linux, Apache, MySQL, and PHP stack; it does not specify one application layout. A small PHP site, a CMS, and a framework application can all require different deployment steps. Start with the project's own entry point, dependencies, writable directories, and database requirements.
Set the web server's document root to the directory intended for public requests. A framework may provide a dedicated public directory while keeping application source and configuration elsewhere. Confirm that deployment does not expose repository metadata, environment files, package caches, or database exports through a public path.
If Composer or a frontend build is part of the project, record the appropriate installation and build steps. Create a complete release package before switching traffic to it. Keep configuration values supplied by the environment and preserve writable application state outside replaceable release directories.
Decide which files the running application may modify. A CMS may manage uploads, caches, or installed extensions through administrative actions. Reconcile that behavior with the code deployment policy so a release does not silently remove valid production changes or preserve unknown executable files indefinitely.
Match the host to the runtime
A host that serves static files can publish Hugo output without running the Hugo tool during requests. A Django application needs support for its application process and service connections. A PHP application needs the PHP execution path its framework expects. Repository integration by itself proves none of these capabilities.
On shared hosting, check which runtime versions, command-line operations, scheduled jobs, and deployment destinations are actually available. On a VPS, assign ownership for runtime installation, process supervision, operating-system maintenance, and recovery. More control also means more responsibilities must be documented.
For a managed platform, map its terminology to your four application questions. Determine where build commands run, where secrets are supplied, which directories persist, and how database access works. Keep the project understandable even if the platform later changes.
Build once, then promote deliberately
Prefer a release process that identifies a specific commit and produces an inspectable artifact. Run appropriate checks before promotion: generated link checks for a static site, representative application tests for a service, and migration review for a database-backed change.
Use staging to exercise the same release procedure with different environment configuration. A staging site assembled by unrelated manual steps cannot confirm that the production procedure is repeatable. Record any required manual action beside the release, including who performs it and how completion is checked.
Define a small set of post-release checks based on user tasks. Confirm a representative page, an important asset, a relevant authenticated action, and any changed data flow. A successful file upload or process restart does not prove the application is usable.
Inspect the package before it reaches the host
Create a small release manifest recording the source commit, build command, runtime requirements, and package contents. For Hugo, identify the generated output directory. For Django, identify application code, static asset output, and migration requirements. For a PHP project, identify the public entry point, installed dependencies, and persistent directories excluded from replacement.
Compare that manifest with the actual package. A missing dependency directory and an accidentally included database export are different errors, but both become visible when package ownership is explicit. Have the deployment process reject an incomplete package before it replaces a working release. Keep the manifest with the artifact so recovery does not depend on locating an old build log.
Make rollback specific to the change
For Hugo, rollback often means promoting a previously verified static artifact and checking cached content. For Django or PHP applications, an older code package may depend on a database structure that has already changed. Decide whether rollback means reversing code, restoring data, or applying a forward repair.
Keep the previous release and the information needed to reconnect it to its environment. Test recovery on an isolated destination. Record how long-lived workers, scheduled jobs, uploaded files, and externally cached assets should behave during the transition.
The backup and security hub helps turn these distinctions into a restore inventory. Backup ownership should follow persistent state, while release ownership should follow the code and build outputs being promoted.
Frequently asked questions
Should production run a Git pull directly?
It can be part of a controlled process, but the command alone does not install dependencies, run checks, manage migrations, or ensure a complete release becomes visible together. Document those surrounding steps and prevent unrelated working-directory changes from becoming part of the release.
Can one repository contain several stacks?
Yes, if the repository clearly identifies each component's source directory, build command, release artifact, and runtime. Give each component an explicit deployment path. Avoid rebuilding and releasing unrelated services merely because they share a repository.
Do generated files always belong outside Git?
The right policy depends on the delivery mechanism. Prefer reproducible generation, but document any platform requirement to commit outputs. Keep source and deployment output clearly distinguished, and identify which tool or process is allowed to regenerate those files.
Let the application define the release
Git gives all three stacks a common history and review process. The deployment plan must still account for each stack's build outputs, runtime, and persistent data. Make those boundaries visible in the repository documentation, then verify a complete release and recovery path before treating a push as a production workflow.
