Run an application

Install the runtime and application

Use a supported runtime source, deploy a pinned application revision, install production dependencies, and test it on localhost first.

8 minute lesson

~~~

Install the runtime version declared by the project. Follow the runtime’s current official Ubuntu instructions or a maintained package source whose update behavior you understand. Do not copy an old installation script into a root shell without reading where it comes from and what it changes.

Verify the tools before deploying:

node --version
npm --version
git --version

The Node version must satisfy the application’s declared requirement. A successful command is evidence about the installed executable, not proof that the application supports it.

Create a release from a pinned Git commit:

cd /srv/notes-app/releases
git clone https://github.com/your-account/notes-app.git 4f92c1a
cd 4f92c1a
git checkout 4f92c1a
npm ci
git rev-parse HEAD

Replace the repository and commit with the real values. npm ci follows the lockfile and fails when it disagrees with package.json. Do not replace that useful failure with an unreviewed dependency update on the server.

If the server performs a production build, run the documented build and then use npm prune --omit=dev to remove build-only packages. If a trusted build system already produced the deployable artifact, install production dependencies with npm ci --omit=dev instead.

Then give the runtime account read access without making it the owner of the release:

sudo chown -R deploy:notes-app /srv/notes-app/releases/4f92c1a
sudo chmod -R g=rX,o= /srv/notes-app/releases/4f92c1a

Start it temporarily on localhost using the project’s real start command:

sudo -u notes-app env HOST=127.0.0.1 PORT=3000 npm start

From another SSH session, verify the private endpoint:

curl --fail --show-error http://127.0.0.1:3000/health
sudo ss -lntp | grep ':3000'

The health request should succeed, and the listener must use 127.0.0.1, not 0.0.0.0. Stop the temporary process after the test. We will let systemd manage it next.

Common failures are a wrong runtime version, a missing production dependency, or a start command that assumes another working directory. Fix the release rather than opening the internal port publicly.

Your action is to record the commit hash, runtime version, clean install result, health response, and bind address. Keep the previous release directory for rollback.

Lesson completed

Take this course offline

Get every free book and course as PDF and EPUB files.

Get the download library →