Connecting Hostinger to VS Code, Git and SSH without breaking production

Connecting a local editor to a live server feels efficient. You open the project, change a file, save, and the site updates. It also removes most of the friction that protects production from a tired afternoon mistake. The goal is not to avoid remote access. It is to use it without making the live site the only copy of anything.

This guide covers a safe setup for a Hostinger account: verifying what your plan supports, connecting with SSH keys, using VS Code Remote SSH for inspection, and deploying through a reviewed commit rather than editing live files by hand.

1. Confirm what your plan actually supports

Before you install an extension or generate a key, log in to hPanel and check the features for the specific website or plan. The relevant sections are usually under Advanced or Website for SSH access, Git, cron jobs and Node.js. Availability differs between shared hosting, cloud hosting, VPS and managed WordPress.

• Is SSH enabled for this account, and what host, port and username are shown?
• Does the plan support the runtime your application needs, including the required Node.js or PHP version?
• Is there a Git deployment feature, or will you deploy with a script or CI workflow?
• What is the exact application root for this site? Do not guess.
• Can you create a staging site or a separate test environment?
• Where are backups stored, and how do you restore one?

Write the answers down. A deployment process built on assumptions about the plan is a process that fails at the worst possible moment.

2. Use SSH keys, not passwords

Generate a dedicated key pair for the workstation. On macOS or Linux, the command is straightforward. On Windows, use the OpenSSH client that ships with modern Windows or Git Bash. Do not reuse your personal GitHub key for a hosting account if you can avoid it.

ssh-keygen -t ed25519 -C "workstation-hostinger" -f ~/.ssh/hostinger_ed25519

# Copy the public key only
cat ~/.ssh/hostinger_ed25519.pub

Add the public key in hPanel under the SSH access section for your account. Keep the private key on your machine and never paste it into a chat, a ticket, a repository or a screenshot. If the key is exposed, revoke it and generate a new pair.

3. Configure VS Code Remote - SSH

Install Microsoft's Remote - SSH extension from the VS Code marketplace. Then add a host entry to your SSH config. The values below are placeholders; copy the real host, port and username from your own hPanel.

Full size

Host my-hostinger-account
    HostName hosting.example.net
    Port 65002
    User account-user
    IdentityFile ~/.ssh/hostinger_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

The port 65002 shown above is a common example on some shared Hostinger accounts, but it is not universal. Use the port in your panel. The same applies to the hostname. If the connection fails, read the exact error before changing settings.

4. Make Git the source of truth

The safest deployment is one where the live site is built from a commit you can identify. The exact mechanism depends on the plan: a provider Git integration, a CI workflow, or a script that pulls a specific branch. The principle is the same: no untracked edits on production.

• Keep the production branch protected and review changes before merging.
• Tag or record the commit that is live. “The latest main” is not a version.
• Build and test locally or in staging before deploying.
• Run database migrations as a separate, reviewed step with a backup.
• Keep environment variables in the host's environment settings, not in the repository.
• Know how to redeploy the previous known-good commit.

5. Deploying a Node.js or Next.js app

A Node application needs more than file upload. It needs a supported runtime, a build step, environment variables, a start command and a process manager or application server. Shared hosting may support Node.js through a managed application feature, but not every framework or configuration. Verify before you build the workflow around it.

For Next.js, confirm whether the host supports the output mode you are using. A standalone build, a static export and a server-rendered app have different requirements. If the plan only supports static files, a server-rendered app will not work no matter how the files are uploaded.

6. Environment variables and secrets

Keep production secrets in the hosting control panel or the CI provider's secret store. Use separate values for local, staging and production. Rotate any credential that has been committed, pasted into a ticket or shared in a screenshot.

• Never commit .env, .env.local or database dumps.
• Use least-privilege database users for the application.
• Restrict admin panels and SSH by IP where the host supports it.
• Enable two-factor authentication on the hosting account and the registrar.
• Keep an offline record of recovery codes.
• Remove access for former employees and agencies promptly.

7. Backups, migrations and rollback

Before a production change, take a backup you can restore. For a database-backed site, that means both the files and the database. Test the restore process on a staging copy if you have never done it. An untested backup is a hope, not a recovery plan.

8. Common connection problems

VS Code Remote SSH is a convenience, not a substitute for a deployment process. The safest workflow is still: change locally, review the diff, test, commit, deploy the commit, verify, and keep a rollback ready. The server should be a place where code arrives, not a place where code is invented.

If the only copy of a change is on the production server, it is not deployed. It is at risk.