Getting the work in front of users
Deploying places a new or updated site or application into its runtime environment so it can be used.
For a website that means sending files to the production server and, as needed, installing dependencies, updating the database, clearing caches, and verifying the result. It can be a single file copy or an automated sequence of steps.
How it differs from pushing
Pushing sends Git commits to a remote repository such as GitHub. Deploying puts the built result into the environment your users reach.
They are different actions, though many projects trigger a deployment automatically when something is pushed or merged into the main branch. In that setup, the push is the trigger, not the deployment itself.
Production, staging, development
- Development: where you edit and check locally
- Staging: a production-like environment for pre-release verification
- Production: what real users reach
Git’s staging area and a staging environment are unrelated despite the shared word. Context tells you which one is meant.
Deploying safely
Before going to production, confirm the branch, the test results, the configuration values, the backup, and how you would roll back. GitHub Environments can require approval, restrict which branches deploy, and hold secrets.
The same care applies when asking an AI to deploy. It reaches further than a commit or a push, and it directly changes what users see, so the target and the blast radius should be confirmed first.
Deploy and release are often used interchangeably but are not always the same. A feature can be deployed while hidden behind a flag, then released later by turning it on. Where teams differ, separate the two ideas explicitly: placed on the server, and made available to users.