What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Automatic deployment can be as simple as pushing a selected Git branch and having a Linux VPS update the live files. For a small, single-server project, a bare repository with a post-receive hook is compact and dependable. When you need builds, tests, secrets, approvals, or a record of each release, a hosted workflow such as GitHub Actions is usually the better boundary between source control and production.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide shows both designs, the security model they require, and the build, migration, health-check, reload, and rollback decisions that turn a push trigger into a production deployment rather than an unsafe file copy.
As an Amazon Associate I earn from qualifying purchases.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchChoose the deployment architecture first
There are two practical ways to deploy Git code automatically to one or more VPS instances.
| Decision area | Bare repository and post-receive hook |
GitHub Actions over SSH |
|---|---|---|
| Where the trigger runs | On the VPS, immediately after a Git push reaches the bare repository. | In a hosted runner after a push, manual dispatch, schedule, or repository-dispatch event. |
| Build and test support | Possible, but every command runs on the server and must be maintained there. | Natural fit for checkout, dependency installation, tests, artifact creation, and then deployment. |
| Credential exposure | The server accepts Git pushes and the hook has access to the deployment target. | The runner receives a private deployment key from a repository or environment secret; the VPS stores only the public key. |
| Auditability and approvals | Mostly server logs and Git history. | Workflow history, environments, branch rules, approvals, concurrency controls, and protected secrets. |
| Operational complexity | Smallest setup for one VPS and a simple application. | More configuration, but clearer separation of build and release responsibilities. |
| Best fit | A small static site or application with one target and a trusted push path. | Projects that must pass tests, deploy to multiple environments, or require production approval. |
Use the hook when the server is intentionally the receiving endpoint and the deployment is short. Use a hosted workflow when a commit should be built and tested before it can reach production, or when several people need a visible release record. In either design, the trigger must be restricted to the intended branch and the deployment account must have no more authority than the application requires.
#1 Best Overall
- [Ultra-Lightweight Ear Buds Designed for Small Ears] Each earbud weighs only 3.7g and features a compact, ergonomic in-ear design made especially for small ears. Secure, low-profile, and comfortable for workouts, all-day wear or overnight sleeping.The ultra-slim profile sits flush in your ear with no hard edges poking or rubbing, so you can even sleep on your side without discomfort.
- [Immersive Stereo Sound with TOZO OrigX Technology] TOZO OrigX tuning delivers clear vocals, balanced mids, and natural stereo sound for music, podcasts, and videos.
- [Long Battery Life for Daily Use] Get up to 7 hours of playtime on a single charge, with up to 32 hours total using the charging case—ideal for workdays, commuting, and extended listening sessions.
- [Bluetooth 5.3 & Stable Connection] Bluetooth 5.3 provides fast pairing, stable wireless performance, and reduced dropouts as you move around home or office.
- [Deep Bass with Clear Vocals] High-performance drivers produce punchy bass while keeping vocals clean and detailed for everyday listening.
Prerequisites and a safe target layout
Before configuring automation, confirm that you can perform a normal manual deployment. You need:
- A Linux VPS with working SSH access and a running web server or application runtime.
- A Git repository and a branch that is explicitly designated for deployment, such as
main. - A dedicated deployment account, separate from your personal login and preferably without interactive administrative privileges.
- A deployment directory owned by the account or group that must write releases and read application files.
- Knowledge of the application’s build, migration, health-check, reload, and restart commands.
- A rollback plan that does not depend on guessing which files changed in the last commit.
Keep source reception, releases, and the live target separate. A useful layout is:
Recommended Free Tools
/srv/git/site.git # bare repository, no working tree
/srv/www/site/releases # immutable or timestamped releases
/srv/www/site/current # symlink or directory served by the application
/srv/www/site/shared # uploaded files and environment-specific dataA static site can use a single target directory. For an application with dependencies or database migrations, timestamped releases and a current symlink make rollback safer because the previous release remains intact.
Architecture A: deploy from a VPS-side bare repository
A bare repository has Git objects and references but no checked-out working tree. It is an SSH-accessible receiving endpoint. Git runs its post-receive hook after accepting a push, and the hook checks out the selected branch into the directory used by the web server or application.
1. Create a constrained deployment account and directories
Run these administrative commands as an existing administrator, replacing names and paths with your values:
sudo adduser --disabled-password --gecos '' deploy
sudo mkdir -p /srv/git/site.git /srv/www/site
sudo chown -R deploy:deploy /srv/git/site.git /srv/www/site
sudo chmod 750 /srv/git /srv/wwwGive the deployment account only the filesystem access it needs. If the web server runs as another user, use a shared group and carefully chosen directory permissions rather than making the entire tree world-writable. Do not put application secrets inside the Git working tree.
2. Initialize the bare repository
sudo -iu deploy git init --bare /srv/git/site.gitFrom your development machine, add the repository as a remote and make the first push:
Rank #2
- 【IP68 Waterproof Multifunctinal Smart Watch】Torjalph fitness activity tracker smart watch is IP68 waterproof technology ,you can wear it when swimming,handwashing,it's rain-proof which means that you perform multiple exercise modes outside without worrying about sweat or rain corroding your fitness smart watch,and this watch equipped with a 230 mAh large capacity battery magnetic charging ,and this sports activity tracker watch can be used 5-7 days If fully charged.
- 【Larger 1.83'' Full Screen Watch & Multi-dial Selection】1.83 inch full HD color touch screen smart watch for men / women provides excellent 240*284 resolution image quality ,This Bluetooth smart watch offers a better touch experience and remarkable immersion and ,more than 200 watch faces for you to choose from App"Da Fit ", you can change the dial style according to your mood to wear keeping the world on your wrist
- 【Accurate Activity Tracker Smart Watch 】sports watch activity tracker uses sweat and dust resistant breathable silicone strap, our Fitness Tracker Smart Watch for Android iOS Phones supports 12 sports modes,walking,running,bicycle,swimming,badminton,basketball,football,rope skipping. This bluetooth calls smart watch for men women is lightweight and stylish, bringing more convenient and relaxing sports experience while also providing more protection.
- 【Your 24 Hour Personal Daily Health Monitor】Fitness watch for women men full touch screen IP67 waterproof bluetooth smartwatch for Android iOS Phones with heart rate blood pressure monitor multifunction Andriod smart watch with steps counter sleep monitor sports fitness watch, monitoring blood oxygen saturation allows you to understand your physical condition in real time to track fitness progress ,to know your health status in time.
- 【More Functions Bluetooth Call Smart Watch】This fitness activity smart watch full screen for iPhone and Android phones includes a bunch of new features including:The bluetooth smart watch can hang up the phone, receive and display WhatsAPP /Text /Facebook /Twitter /Messenger reminder.Support sedentary reminder, alarm clock, stopwatch, timer,weather information,music control, remote camera control compatible with Android 5.0 and above or iOS 9.0 and above smartphones.
git remote add vps ssh://deploy@example-vps:/srv/git/site.git
git push vps mainUse the real host name, port, account, and branch. The first push will invoke the hook only after the hook exists; create it before relying on the deployment.
3. Install a branch-checking post-receive hook
Create /srv/git/site.git/hooks/post-receive as the deploy user and make it executable:
#!/bin/sh
set -eu
GIT_DIR=/srv/git/site.git
TARGET=/srv/www/site
DEPLOY_BRANCH=main
while read -r oldrev newrev refname
do
case "$refname" in
refs/heads/main)
;;
*)
printf '%sn' "Ignoring $refname" >&2
continue
;;
esac
doneThe example above shows the required reference validation, but a real hook must also perform the checkout and deployment work. A complete minimal version is:
#!/bin/sh
set -eu
GIT_DIR=/srv/git/site.git
TARGET=/srv/www/site
DEPLOY_BRANCH=main
while read -r oldrev newrev refname
do
[ "$refname" = "refs/heads/$DEPLOY_BRANCH" ] || {
printf '%sn' "Ignoring $refname" >&2
continue
}
printf '%sn' "Deploying $newrev to $TARGET" >&2
git --work-tree="$TARGET" --git-dir="$GIT_DIR" checkout -f "$DEPLOY_BRANCH"
# Add only commands required by this application.
# npm ci --omit=dev && npm run build
# python -m pip install -r requirements.txt
# php artisan migrate --force
# sudo systemctl reload example.service
doneReplace the commented commands with the commands for your stack. Do not copy all of them into one application. The hook should exit nonzero when checkout, a build, a migration, or a restart fails; Git then reports a failed receive instead of silently claiming success. Send useful status to standard error so the person pushing can see what happened, and also log deployment output on the server.
4. Handle build output and permissions deliberately
A checkout updates tracked files but does not install dependencies or generate assets. Decide whether the generated output belongs in Git or is produced during deployment. For a static site, a build might write to a temporary directory and then replace the target atomically. For a Node.js, Python, or PHP application, install dependencies into the release directory, keep virtual environments or dependency directories out of the shared data path, and ensure the service user can read the result.
Database migrations need special care. Run an idempotent migration command as a deployment step only when the migration tool and database permissions are designed for unattended execution. Never place a database password directly in the hook. Read it from a protected environment file or secret mechanism with permissions limited to the deployment process.
5. Make the hook safer than a blind checkout
- Use absolute paths; hooks do not necessarily run with the interactive shell’s working directory or environment.
- Reject every reference except the intended branch. A tag or feature branch should not alter production.
- Use a temporary build or release directory when a partial build could leave the live directory unusable.
- Run a health check before switching traffic or restarting the service.
- Record the commit ID, start time, end time, and exit status.
- Keep the hook owned and writable only by the deployment administrator and deployment account as appropriate.
Architecture B: GitHub Actions deploying over SSH
GitHub describes Actions as a way to create custom continuous-deployment workflows directly in a repository. A workflow can react to a push on a selected branch, build and test the project, and copy files or an artifact to the VPS. It can also be started manually or on a schedule when that is useful for a release process.
Rank #3
- [Low Noise High Fidelity] New bee guitar cord with 22AWG oxygen-free-copper center conductors provides enhanced signal transfer, the PVC insulation material and the high-density stranded copper double shield provide noise rejection for quiet operation
- [Ideal for Choice] New bee 1/4 straight and right angle metal connectors, ensures a secure connection in any instrument, pedal, or amp jack. L shape great fro on stage guitar stands
- [Wide Compatible] Suitable for mixer, power amplifier, microphone, effector, decoder, equalizer, electoronic organ, electric guitar, electric bass and other electronic equipments. Widely used in the installation of smart home, karaoke speaker, professional stage audio, etc
- [Easy Disassemble] Making incidental repairs quick and easy! Very nice, flexible cable
- [Dont Hesite to Order] 24 hours customer services and professional technology team are standing by
1. Create a deployment-only SSH key
Generate a dedicated key pair on a trusted workstation or in the approved key-management process:
ssh-keygen -t ed25519 -C 'production-deploy' -f ~/.ssh/production_deployInstall only production_deploy.pub in the deployment account’s ~/.ssh/authorized_keys on the VPS. Store the private key, production_deploy, as a protected repository or environment secret. Do not commit it, put it in a workflow file, or print it during a run.
Use separate keys for staging and production. Rotate a key when a person leaves the project, the runner trust boundary changes, or the key may have been exposed. A deployment key should log in as the least-privileged account practical and should not be reused for administration.
2. Establish host-key verification
The workflow must verify that it is connecting to the intended VPS. A convenient first-connection command is:
ssh-keyscan -p 22 example-vpsDo not blindly trust that output for a sensitive production deployment. Obtain the expected host key or fingerprint through a trusted channel, verify it, and save the verified lines as a protected KNOWN_HOSTS secret or equivalent runner configuration. The workflow should fail if the presented key does not match.
3. Add repository and environment values
Typical values are:
| Name | Store as | Purpose |
|---|---|---|
VPS_HOST |
Repository or environment variable | DNS name or address of the VPS. |
VPS_USER |
Variable | Dedicated deployment account. |
VPS_PORT |
Variable | SSH port, if it is not the default. |
VPS_PRIVATE_KEY |
Secret | Private half of the deployment-only key. |
VPS_KNOWN_HOSTS |
Secret | Verified host-key entries. |
Put production values in a protected production environment rather than exposing them to every branch. Environment protection can require an approval before the job receives its secrets.
4. Trigger only the release branch
A minimal workflow skeleton is:
name: Deploy
on:
push:
branches:
- main
workflow_dispatch:
jobs:
build-test-deploy:
runs-on: ubuntu-latest
environment: production
steps:
- name: Check out source
uses: actions/checkout@v4
- name: Install dependencies
run: <your dependency-install command>
- name: Run tests
run: <your test command>
- name: Build
run: <your build command>
- name: Configure SSH
shell: bash
run: |
install -m 700 -d ~/.ssh
printf '%sn' "$VPS_KNOWN_HOSTS" > ~/.ssh/known_hosts
printf '%sn' "$VPS_PRIVATE_KEY" > ~/.ssh/deploy_key
chmod 600 ~/.ssh/deploy_key
env:
VPS_KNOWN_HOSTS: ${{ secrets.VPS_KNOWN_HOSTS }}
VPS_PRIVATE_KEY: ${{ secrets.VPS_PRIVATE_KEY }}
- name: Copy release
run: |
rsync -az --delete
-e "ssh -i ~/.ssh/deploy_key -p $VPS_PORT"
./ "$VPS_USER@$VPS_HOST:/srv/www/site/"
env:
VPS_HOST: ${{ vars.VPS_HOST }}
VPS_USER: ${{ vars.VPS_USER }}
VPS_PORT: ${{ vars.VPS_PORT }}The expressions and commands are intentionally placeholders. Replace them with your project’s real dependency, test, and build commands. If the build emits a directory such as dist, copy that directory rather than the repository root. Be cautious with --delete: it removes destination files that are absent from the source, so never point it at a directory containing uploads, runtime state, or secrets.
Rank #4
- Digital Family Calendar: BSIMB digital calendar wall touch screen puts an end to your chaotic life. Designed for busy families, the digital calendar keeps you organised and in step with your family. Assign different colours and tasks to each family member to make family scheduling easier and more intuitive.
- Easy Setup and Auto-Sync: Plug in, connect to WLAN and auto-syn your electric calendar in minutes. Digital wall calendar compatible with Google calendar, iCloud calendar, Outlook calendar, Cozi calendar and Yahoo calendar. Add events directly on the device or through the ecalendar app. Electronic calendar stays current whether you're at work or traveling—no manual updates needed.
- All-In-One Home Assistant: Smart calendar builds habits and encourage independence with personalised chores. Display daily meal plan to reduce the daily ‘What's for dinner?’ stress. To-do lists keep track of everything you want. Turning chores into valuable achievements with stars and rewards, making life easier and more enjoyable.
- Manage Anytime Anywhere: BSIMB electronic calendar for family stay connected with the powerful ecalendar app. Access and manage your digital wall calendar anytime, anywhere with free features like stars & rewards, photo screensaver, chore charts, meals plans, to-do lists etc. Electronic planner paid features like Magic Import tailor advanced tools for users with special needs.
- Stay in Touch with Loved Ones: Share photos or videos from your phone to electronic wall calendar with app, instantly update your life moment, and keep in touch with your family, especially those who are far away; you can also surprise your smart calendar digital wall by sending him a wish card; it's also great for keeping tech-illiterate elders in touch with the youngsters.
5. Separate copying from server-side activation
For a simple static site, copying the built files into a dedicated web root may be enough. For an application, have the workflow upload a release archive or directory, then invoke a short server-side activation command over SSH. That command can install production dependencies, run migrations, execute a local health check, switch the current symlink, and reload the service. Keeping activation on the VPS means the service restart and health check occur close to the files they affect.
Stack-specific deployment steps
There is no universal build or restart command. Select only the branch that matches your application.
Static HTML, CSS, and JavaScript
- Install the required toolchain in the runner or build directory.
- Run the project’s documented build command, if any.
- Copy only the generated public directory to a release path.
- Check that the expected index file and asset manifest exist.
- Reload the web server if configuration changed; static-file updates often need no process restart.
Node.js
- Pin the runtime version used by the application and run a lockfile-respecting install such as the project’s approved equivalent of
npm ci. - Run unit tests and the production build before opening the release to traffic.
- Install production dependencies in the release or use a prebuilt artifact.
- Reload the process manager or service only after the health endpoint responds successfully.
Python
- Use the application’s supported Python version and create or reuse a release-specific virtual environment.
- Install locked dependencies, run tests, collect static assets if required, and apply migrations with the project’s migration tool.
- Reload the WSGI or ASGI service after the health check passes.
PHP
- Install locked Composer dependencies with production options appropriate to the project.
- Build frontend assets before activation if the application requires them.
- Run framework migrations in noninteractive production mode only when this is an approved part of the release.
- Reload PHP workers or the application service when code or configuration requires it.
Keep migrations, cache warmers, queue restarts, and one-time data transformations explicit. A compromised or accidental commit should not be able to make the deployment account run arbitrary administrator commands.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Release directories, health checks, and rollback
Use immutable releases when downtime matters
Instead of overwriting the live directory, create a directory named with the commit ID or a timestamp, build there, and leave the previous release untouched. A successful activation can then update a symlink:
Free tools Windows power users keep installed
One-click scans. No signup required.
ln -sfn /srv/www/site/releases/COMMIT_ID /srv/www/site/currentPoint the web server or service at current. Keep shared uploads, sockets, and environment files outside the release directories and link them in with controlled permissions.
Check before and after activation
A useful deployment sequence is:
- Verify the commit and branch that triggered the deployment.
- Build and run automated tests.
- Install dependencies and prepare the release directory.
- Run migrations that are backward-compatible with the currently running version.
- Run a local or private health check against the new files.
- Switch the live symlink or copy the approved artifact.
- Reload or restart the service.
- Run an external health check and inspect logs.
- Mark the release successful only after the checks pass.
Health checks should test the behavior users need, not merely whether a process exists. Check an HTTP status, a small database query if appropriate, required static assets, and a dependency such as a queue only when that dependency is part of the service’s availability contract.
Define rollback before the first production push
With release directories, rollback is a symlink change to the last known-good release followed by a service reload. With a single checkout directory, record the previous commit and be prepared to run:
git --work-tree=/srv/www/site --git-dir=/srv/git/site.git checkout -f PREVIOUS_COMMITThat command restores tracked files but does not restore database rows, uploaded files, or external side effects. Prefer backward-compatible migrations, database backups, and a documented reversal procedure. In a hosted workflow, keep successful release identifiers and redeploy the prior artifact rather than rebuilding an unpinned historical commit.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Production controls for GitHub Actions
GitHub environments provide fine-grained control over deployments. Use them when a production push needs more than a successful build.
- Environment approval: require one or more reviewers before the job receives production secrets.
- Branch restrictions: allow only the protected release branch or approved tags to target production.
- Concurrency: allow one production deployment at a time so an older run cannot finish after a newer run and overwrite it.
- Protection rules: require status checks or other gates before activation.
- Secret separation: keep staging and production keys, hosts, and credentials in different environments.
- Log hygiene: never echo private keys, tokens, database passwords, or complete environment dumps.
Also protect the branch in the repository itself. Require review and passing checks before a commit can reach the branch that the deployment trigger watches. If you intentionally allow manual production dispatch, make the selected ref visible in the workflow and validate it on the server.
Security checklist for either design
- Create a deployment-only key; do not reuse a personal administrative key.
- Install only the public key on the VPS and restrict the account’s filesystem and service permissions.
- Verify the VPS host key through a trusted channel before placing it in an automation secret.
- Reject unexpected branches and references in the hook or workflow.
- Use absolute paths and pinned dependency versions.
- Keep secrets outside Git and outside publicly served directories.
- Rotate keys after personnel, runner, or infrastructure changes.
- Make builds and migrations fail closed; a failed command must stop activation.
- Keep deployment logs, but redact credentials and sensitive configuration.
- Test with a harmless change in a non-production target before enabling production release.
Troubleshooting automatic deployments
The push succeeds but nothing changes
Confirm that the pushed reference is exactly the configured branch, that the hook is executable, and that its absolute GIT_DIR and target paths exist. Inspect the server’s hook output and file ownership. A hook that ignores every reference will make the Git push appear successful while intentionally doing no deployment.
The workflow cannot connect by SSH
Check that the public key is in the deployment account’s authorized_keys, the private-key secret preserves line breaks, the selected port is correct, and the runner’s known-hosts entry matches the VPS key. Test the same account manually from a controlled machine without copying the private key into logs.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteFiles arrive but the application is broken
Check runtime versions, dependency installation, generated assets, environment-file permissions, and service logs. A successful rsync proves only that files were transferred. Add a release-local health check and do not switch the live target until it passes.
A newer deployment is overwritten by an older run
Cancel superseded workflow runs or configure a production concurrency group. On the server, record the commit being activated and reject an activation that is older than the current release unless it is an explicit rollback.
Rollback restores code but not data
Code rollback cannot undo a destructive database migration or an external API side effect. Use expand-and-contract migrations, backups, reversible data changes where possible, and a runbook that names the data recovery decision separately from the code rollback.
Testing the setup before production
- Create a staging target or an isolated directory on the VPS.
- Make a harmless visible change, such as a page footer update.
- Push only the configured deployment branch, or start the workflow manually with the intended ref.
- Confirm that the expected commit ID, build output, and service reload appear in logs.
- Exercise the health endpoint and verify that unrelated uploads and environment files were not deleted.
- Force a controlled failure, such as a deliberately failing test in staging, and verify that activation stops.
- Perform a rollback to the prior release and confirm that the health check returns to normal.
Only after these checks should the production host, production environment, and production secrets be enabled.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Which approach should you use?
Choose a bare repository hook when one VPS is the deliberate receiving endpoint, the application has a short deployment path, and you value minimal moving parts. Choose GitHub Actions when the repository must build and test before release, secrets should be separated by environment, several targets are involved, or production requires approvals and an auditable workflow. Both approaches can be secure: the deciding factors are least privilege, strict branch validation, verified host keys, explicit stack commands, health checks, and a rollback that you have actually exercised.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
