How to Set Up SSH, SFTP, and Git Deployment on a Web Server

Overview

This article gives you a working model for ssh web server setup, sftp hosting access, and git deployment on server without tying the process to one hosting provider or one Linux distribution. The exact commands may vary slightly across environments, but the checklist stays useful because the underlying decisions are stable: who gets access, where code lives, how files are published, and how you avoid permission drift over time.

Before you begin, make sure you know which type of hosting you actually have. On some shared hosting plans, SSH is limited or disabled, Git hooks may be restricted, and shell access may be locked to a specific home directory. On a VPS hosting or cloud hosting environment, you typically have more control, but you also own more of the security and deployment responsibility. If you are still deciding which setup fits your project, it helps to compare environments before you build a deployment process that your host does not support. Related reading: Shared Hosting vs VPS vs Cloud Hosting: Which Option Fits Your Website in 2026?.

At a high level, the cleanest pattern looks like this:

• Use SSH keys instead of passwords for administrative access.
• Use SFTP for direct file transfer when you need it, not as your main deployment method.
• Keep your Git repository outside the public web root when possible.
• Deploy from a checked-out working tree, a release directory, or a build artifact, rather than serving a raw repository directly.
• Separate system users, application files, and writable runtime directories.
• Test on staging before pushing production changes.

If your project is WordPress or another CMS, consider pairing this article with a staging workflow so deployment does not become your first test environment. See WordPress Staging Site Guide: How to Test Changes Safely Before Going Live.

Checklist by scenario

Use the scenario below that matches your hosting environment and workflow. The right setup is not the one with the most moving parts. It is the one your team can operate consistently.

Scenario 1: Single site on a VPS or cloud server

This is the most flexible setup for a personal project, business application, or lightweight production site.

1. Create or confirm a non-root user. Keep routine administration out of the root account. Use root only when needed for system-level changes.
2. Install and enable OpenSSH server if your image does not include it. Confirm the service starts on boot.
3. Add your public SSH key to the user account. Store keys in ~/.ssh/authorized_keys with restrictive permissions on the .ssh directory and file.
4. Disable password authentication if you have confirmed key-based access works. This reduces the attack surface on internet-facing servers.
5. Optionally change the SSH port and restrict login users. A port change is not a substitute for security, but it can reduce noise. Restricting allowed users is usually more valuable.
6. Configure a firewall. Allow SSH, web traffic, and only the other services your stack actually needs.
7. Use SFTP through the same SSH service. In many Linux environments, SFTP is already available as part of SSH. This avoids opening a separate FTP service.
8. Create a project structure. A common layout is a repository directory, a release or current symlink, and a shared writable directory for uploads, logs, or cache.
9. Install Git on the server. Use it for pulling code, checking out tags, or handling a bare repository deployment flow.
10. Keep the bare repo or clone outside the public web root. Your web server should point to the published application files, not to your Git metadata.
11. Choose a deployment pattern. For simple sites, a server-side git pull may be enough. For cleaner rollbacks, use release directories and a current symlink.
12. Set ownership and group permissions deliberately. The deployment user and web server process need a plan for read and write access that does not rely on broad permissions.
13. Restart or reload services only when needed. Avoid making every deploy depend on manual web server restarts if code changes do not require it.

Scenario 2: Shared hosting with limited shell access

Shared hosting can still support a basic developer workflow, but limits matter.

1. Check whether SSH is enabled by default or by request. Some hosts require activation from the hosting control panel.
2. Confirm Git support. Some shared environments allow Git binaries but restrict hooks or background processes.
3. Use SFTP instead of FTP. If your provider offers both, prefer the encrypted option.
4. Ask where your web root is. Common paths differ between providers, and publishing to the wrong directory is a frequent source of confusion.
5. Avoid assuming you can bind services or install system packages. Build your workflow around what the host actually permits.
6. If server-side Git deployment is weak, deploy built artifacts. Push code to your central repository, build elsewhere, and upload the final output through SFTP.
7. Use a staging subdomain if available. This reduces risk when your production environment is limited. You may need to connect DNS first; see How to Connect a Domain to Web Hosting: DNS Records Explained Step by Step.

If shared hosting constraints are starting to shape your application more than your application requirements are shaping hosting, it may be time to move to VPS hosting or a more developer-oriented plan.

Scenario 3: Team access on one server

Once more than one person deploys to the same server, ad hoc access quickly becomes messy.

1. Create individual user accounts. Do not share one SSH login across a team.
2. Use SSH keys per person and rotate access when roles change. Removing one person should not require replacing everyone else's credentials.
3. Standardize a group for project files. This helps maintain predictable access to deploy directories.
4. Document the deployment path. Every team member should know where repositories, releases, environment files, and writable directories live.
5. Decide who can deploy to production. Separate read access from deploy access if needed.
6. Store secrets outside the repository. Environment-specific credentials should not be committed just because several team members need them.
7. Use post-deploy checks. At minimum, validate file ownership, application health, and that the web root points to the expected release.

Scenario 4: Git push-to-deploy on a self-managed server

This is a useful pattern when you want to deploy website with git in a predictable and low-friction way.

1. Create a bare repository on the server. This acts as the receiving repository for your pushes.
2. Create a working tree or release directory separate from the bare repository. The web server should not serve the bare repo contents.
3. Add a post-receive hook. Use the hook to check out the target branch into the working tree or trigger your deployment script.
4. Handle dependencies carefully. If your app needs package installation, asset builds, or cache clearing, define those steps explicitly in the deployment script rather than assuming the server state is already correct.
5. Protect environment configuration. Ensure hooks do not overwrite local production settings.
6. Log deployment output. Even simple hooks benefit from log files when a push appears successful but the application is broken.
7. Keep rollback options simple. Tag stable versions, retain previous release directories, or document the exact Git command to redeploy the last known-good revision.

This approach is often enough for small to medium projects. For more complex delivery pipelines, you may later move the build step into CI and keep the server focused on receiving tested artifacts.

What to double-check

Most server access problems are not caused by the big ideas. They come from a few quiet details that are easy to miss. Review this list before you consider your setup done.

• SSH directory permissions: If ~/.ssh or authorized_keys is too open, key authentication may fail or the configuration may be unsafe.
• Correct user account: Logging in as the wrong user often leads to confusing permission errors later, especially for SFTP uploads.
• Web root path: Confirm whether your public directory is public_html, www, htdocs, public, or a custom path.
• Repository location: The .git directory should not be exposed to the web.
• Ownership model: Decide whether the deploy user, the web server user, or a shared group owns application files.
• Writable directories: Uploads, cache, sessions, and logs often need different permissions from the codebase.
• Hook execution: Git hooks must be executable and written with the correct paths. Relative paths often fail when hooks run in a different context than expected.
• Branch expectations: If production should only deploy from one stable branch, enforce that through your deployment script or documented process.
• Environment files: Confirm that local production configuration survives deploys and is not replaced by defaults from the repository.
• Backups before major changes: Deployment is not the same as backup. If a deploy script deletes files or changes data, have a separate recovery path.
• DNS and hostnames: If you are pointing a new domain or subdomain at the server, make sure DNS is correct before troubleshooting the app itself. Related reading: Domain Transfer Checklist: How to Move Your Domain Without Downtime and How to Choose a Domain Name in 2026: Availability, Branding, SEO, and TLD Tips.

If you host more than one project on the same machine, also double-check site isolation. Separate system users, project directories, and vhost configurations make it much easier to avoid accidental cross-site changes. For a broader setup model, see How to Host Multiple Websites on One Server or Hosting Plan.

Common mistakes

The fastest way to make server access feel unreliable is to mix convenience shortcuts with production permissions. These are the mistakes worth catching early.

Using root for everyday deployment

It is tempting because it removes permission friction, but it also makes mistakes more destructive. A safer pattern is to deploy with a standard user and elevate only when a system change truly requires it.

Relying on FTP when SFTP is available

Plain FTP is the older habit many hosting accounts still expose. SFTP rides on SSH, uses encryption, and usually simplifies account management because you are not maintaining a second service for file access.

Giving the web server write access to everything

When every directory is writable by the runtime user, deployment works until security or file integrity becomes a problem. Limit write access to the specific runtime directories that need it.

Serving the repository directly

A Git working copy inside the public directory may seem convenient, but it increases the chance of exposing internal files and makes deployment side effects harder to control. Publish only the files the web server needs.

Skipping a rollback plan

If your deployment process cannot quickly return to the previous version, it is not finished. Even a simple rollback note in your runbook is better than improvising under pressure.

Editing production files over SFTP after a Git deploy

This creates drift between the server and the repository. If emergency fixes happen on the server, capture them in version control immediately and restore a clean deployment path.

Ignoring DNS during launch troubleshooting

Teams often blame code or the web server when the domain is still resolving to the old host. If the issue appears during migration, review your DNS records and cutover plan. See How to Migrate a WordPress Site to a New Host With Minimal Downtime.

Building a workflow your hosting plan cannot support

If you need shell scripts, background jobs, custom packages, or release symlinks, low-end shared hosting may become a bottleneck. In that case, the hosting decision is part of the deployment decision. You may also want to compare application-specific environments, especially for CMS projects: WordPress Hosting vs Regular Web Hosting: What Actually Changes? and Best Managed WordPress Hosting Features to Look For Before You Migrate.

When to revisit

This setup is not a one-time task. Revisit it when the inputs change, especially before a busy launch period or after your tooling changes.

Use this review checklist:

1. Before seasonal planning cycles: Confirm who still needs SSH access, which repositories are still active, and whether old keys or stale deploy users should be removed.
2. When workflows or tools change: If you move from manual Git pulls to CI-driven releases, or from shared hosting to VPS hosting, update your deployment model instead of layering the new process onto the old one.
3. When team membership changes: Remove old keys, verify deploy ownership, and confirm who can push to production.
4. When you add domains, subdomains, or new environments: Recheck DNS, vhost mappings, and document where each environment publishes files.
5. When permission problems start appearing repeatedly: Do not patch with broad chmod changes. Revisit your ownership model and writable directory plan.
6. When the site architecture changes: Static sites, PHP apps, Node applications, and WordPress installs often need different deploy and runtime handling.
7. After a migration: Verify that SSH keys, firewall rules, SFTP paths, hooks, and scheduled tasks all survived the move.

A practical next step is to turn this article into your own one-page runbook. Document these items for each server: hostname, SSH port, deploy user, repo path, web root, writable directories, branch policy, rollback method, and post-deploy checks. That small document saves time every time you onboard a new developer, rotate access, launch a new site, or troubleshoot a deployment under pressure.

If you are still evaluating hosting for this kind of workflow, compare plans based on shell access, deployment flexibility, and upgrade paths rather than headline pricing alone. For broader planning, see Best Web Hosting for Small Business Websites: Features, Limits, and Upgrade Paths.