Error Tracking for PHP and JavaScript Apps on a VPS with Sentry and Open‑Source Tools

If you run a serious PHP or JavaScript application, relying only on server logs or a few try/catch blocks is not enough. You need a way to see exactly which errors users hit, with stack traces, browser info, request context and deployment versions – ideally in one place and in near real time. That is where dedicated error tracking tools like Sentry and their open‑source alternatives shine. In this article, we will walk through how to wire error tracking into both PHP backends and browser/SPA frontends, and how to host these tools efficiently on your own VPS.

We will look at Sentry (hosted and self‑hosted), explore open‑source options you can run on a VPS, and show how to connect everything into a broader observability stack: logs, metrics and alerts. Along the way, we will discuss performance impact, security, GDPR/KVKK considerations and practical rollout tips based on what we see every day while hosting PHP, Laravel, WordPress and JavaScript apps at dchost.com.

What Error Tracking Really Solves (Beyond Classic Logs)

Before jumping into configuration, it is useful to clarify what dedicated error tracking adds on top of plain log files or basic error_log calls.

Logs vs. event‑based error tracking

Traditional logs (Apache/Nginx logs, PHP error_log, application logs) are line‑based. You can absolutely run serious systems just with good logging – and if you have not yet tuned your PHP logging, you should definitely read our guide on PHP error logging best practices on hosting servers.

However, for debugging real production issues, logs have limitations:

• You need to grep through huge files to connect lines that belong to the same request.
• Front‑end JavaScript errors often never reach server logs at all.
• It is hard to see frequency: is this error happening once a week or 1000 times per hour?
• Grouping similar stack traces and tracking regressions over releases is manual and painful.

Error tracking platforms solve these problems by treating each error as a structured event. They capture:

• Exception type, message and full stack trace
• Environment (production, staging), release version, server host
• User agent, OS, browser, URL and sometimes user ID
• Tags and custom context you add from your code

Then they group similar errors, show trends over time, and notify you when a new issue appears or an old one comes back after a deployment.

Why PHP and JavaScript need slightly different handling

On a PHP backend (Laravel, WordPress, Symfony, custom frameworks), a typical fatal error or uncaught exception will terminate the request. The stack trace is deterministic, attached to a single HTTP request, and you usually have access to the full environment and server logs.

In the browser or in a JavaScript SPA (React, Vue, Angular, plain JS), errors behave very differently:

• They may be swallowed by the framework unless you hook global handlers.
• Users run different browsers, extensions and ad blockers – many will hide or modify requests.
• Source code is usually minified, so raw stack traces are not human‑friendly without source maps.

A good error tracking setup therefore needs to:

• Capture back‑end PHP exceptions centrally.
• Capture front‑end JS errors, with proper source maps and environment tags.
• Correlate both sides via release versions, request IDs or user IDs when possible.

Planning Your VPS for Error Tracking

You can absolutely use a hosted Sentry account, but many teams prefer to self‑host error tracking to control data location, privacy and costs. That is where a VPS comes in. At dchost.com, we see two main patterns:

• App + error tracker on the same VPS: OK for small projects and internal tools.
• Dedicated VPS for observability stack: Recommended once you have multiple apps or higher traffic.

Resource sizing

Error tracking workloads are typically I/O and storage heavy (lots of small write operations, many documents kept for 30–90 days) plus some CPU for processing and grouping events.

As a starting point:

• Small app / single project: 2 vCPU, 4 GB RAM, fast SSD/NVMe, 50–100 GB disk.
• Multiple apps / medium traffic: 4 vCPU, 8–16 GB RAM, 200+ GB NVMe, with room for growth.
• Heavy usage or many teams: Consider a dedicated observability node and centralised logging, e.g. centralised logs with ELK or Loki, alongside Sentry or its alternatives.

If you are unsure how much CPU, RAM and storage you need, our guide on estimating traffic and resource needs for new websites is a good baseline. For error tracking, lean a bit higher on disk and IOPS because of the sustained write pattern.

Security and basic hardening

Because your error tracker will store stack traces, headers, and possibly user identifiers, you must treat that VPS as sensitive. Review the VPS security hardening checklist and at minimum:

• Disable direct root SSH and use key‑based authentication.
• Keep the system updated and enable automatic security updates.
• Restrict inbound ports (typically only 80/443 for the web UI and API).
• Place the error tracker behind HTTPS with a valid SSL certificate.

Setting Up Sentry for PHP on a VPS‑Hosted App

Sentry is one of the most widely used error tracking tools. You can use the SaaS version, or host Sentry yourself on a VPS using Docker. The PHP SDK is the same in both cases; the difference is where the DSN (Data Source Name) points.

Installing the Sentry PHP SDK

For a modern PHP project using Composer, add the Sentry SDK:

composer require sentry/sentry-php

In Laravel, you can also use sentry/sentry-laravel, but we will stay framework‑agnostic here.

Next, initialise Sentry in your app bootstrap (for example, in public/index.php or a framework service provider):

<?php

Sentryinit([
    'dsn' => getenv('SENTRY_DSN'),
    'environment' => getenv('APP_ENV') ?: 'production',
    'release' => getenv('APP_RELEASE') ?: 'unknown',
    'traces_sample_rate' => 0.0, // enable later if you want performance tracing
]);

// Attach user / custom context if available
if (isset($currentUserId)) {
    SentryconfigureScope(function (SentryStateScope $scope) use ($currentUserId) {
        $scope->setUser(['id' => $currentUserId]);
    });
}

// In a global exception handler
try {
    // your app logic
} catch (Throwable $e) {
    SentrycaptureException($e);
    throw $e; // or render a friendly error page
}

Always keep your DSN and API keys out of your code. We recommend placing them in environment variables or configuration files outside the document root. If you are not yet comfortable with this, see our detailed article on managing .env files and secrets on a VPS safely.

Configuring Sentry (cloud or self‑hosted) as the backend

Once you create a project in Sentry’s interface (or in your own self‑hosted instance), you will get a DSN string, which looks like this:

https://[email protected]/1

Set it in your environment:

# .env
SENTRY_DSN=https://[email protected]/1
APP_ENV=production
APP_RELEASE=1.3.0

Self‑hosting Sentry on a VPS with Docker

Sentry provides an official Docker‑based self‑hosted bundle. On a fresh VPS, after hardening and installing Docker + docker‑compose, you can roughly follow this pattern (simplified example):

git clone https://github.com/getsentry/self-hosted.git sentry-self-hosted
cd sentry-self-hosted

cp .env.example .env
# Edit SMTP, SENTRY_SECRET_KEY, database passwords, etc.

./install.sh  # one-time bootstrap

docker compose up -d

By default, this stack will run Sentry, PostgreSQL, Redis, Kafka and related services. Point your DNS (e.g. sentry.yourdomain.com) to the VPS, put Nginx or Caddy in front with HTTPS, and configure the Sentry web UI to use your external URL.

For production, make sure:

• The VPS disk is fast (NVMe if possible) to handle write operations.
• You set backups for the PostgreSQL database and configuration volumes (see our general backup strategy guide with RPO/RTO planning).
• Access to the Sentry UI is restricted (VPN, IP allow‑lists or at least strong authentication).

Setting Up Sentry for Browser JavaScript and SPAs

Server‑side PHP error tracking is only half of the picture; many bugs appear only in certain browsers or devices. Sentry’s JavaScript SDK can capture those errors, link them to releases and use source maps for readable stack traces.

Adding the Sentry browser SDK

For a simple multi‑page PHP site with inline scripts, you can use the CDN snippet:

<script src="https://browser.sentry-cdn.com/7.x.x/bundle.tracing.min.js" integrity="sha384-..." crossorigin="anonymous"></script>
<script>
  Sentry.init({
    dsn: 'https://[email protected]/1',
    environment: 'production',
    release: '1.3.0',
    tracesSampleRate: 0.0 // enable later if you also want front-end performance tracing
  });
</script>

For bundler‑based apps (React/Vue/Angular using Webpack, Vite, etc.), install via npm:

npm install --save @sentry/browser @sentry/tracing

Then configure in your entry file (for example, src/main.js):

import * as Sentry from '@sentry/browser';
import { Integrations } from '@sentry/tracing';

Sentry.init({
  dsn: process.env.VUE_APP_SENTRY_DSN,
  environment: process.env.NODE_ENV,
  release: process.env.APP_RELEASE,
  integrations: [
    new Integrations.BrowserTracing(),
  ],
  tracesSampleRate: 0.0,
});

Uploading source maps

To make minified stack traces readable, you should upload source maps to Sentry as part of your build pipeline. Sentry offers CLI tools and Webpack/Vite plugins that upload source maps during deployment, tagging them with the same release you use in Sentry.init().

Typical flow:

1. Set a release identifier (e.g. git commit hash) in your build environment.
2. Build assets with source maps enabled.
3. Upload source maps with Sentry’s CLI using that release ID.
4. Deploy assets and application.

This way, when a user’s browser throws an error, Sentry can map the minified line/column back to the original source file and line in your repository.

Capturing extra context and user data safely

Both in PHP and JS, you should enrich errors with useful context, but avoid storing sensitive personal data (passwords, card numbers, raw addresses). A common safe pattern is:

• Attach anonymised user identifiers (internal user ID or hashed email), not full PII.
• Capture feature flags, A/B test variants, or tenant IDs.
• Use Sentry’s built‑in data scrubbing to mask known fields (e.g. password, authorization headers).

If you operate in KVKK/GDPR jurisdictions, align your setup with our guide on choosing KVKK/GDPR‑compliant hosting and data localisation. Error tracking data is part of that story.

Open‑Source Error Tracking Alternatives You Can Self‑Host

Sentry is powerful, but not the only choice. If you prefer simpler stacks or different licenses, several open‑source alternatives work well on a VPS. Here are a few options many teams successfully self‑host.

GlitchTip

GlitchTip is an open‑source error tracking platform that implements the Sentry protocol. That means your existing Sentry SDKs (PHP and JS) can often talk to GlitchTip with minimal code changes – you just point the DSN to your GlitchTip host.

Highlights:

• Fewer moving parts than full self‑hosted Sentry.
• PostgreSQL‑backed, Django‑based.
• Works with Sentry SDKs for many languages.

A minimal Docker Compose snippet (simplified example, always check the official docs):

version: '3.7'

services:
  glitchtip:
    image: glitchtip/glitchtip:latest
    env_file: .env
    depends_on:
      - postgres
    ports:
      - "8000:8000"

  postgres:
    image: postgres:15
    environment:
      POSTGRES_DB: glitchtip
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: strongpassword
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

Once running behind your web server and HTTPS, create a project, copy the DSN and plug it into your PHP and JS SDKs just like you would with Sentry.

Exceptionless

Exceptionless is a .NET‑centric but language‑agnostic error tracking solution with a modern web UI and REST API. It supports clients for multiple platforms and can ingest events via HTTP, so PHP/JS integration is straightforward.

Basic Docker example:

version: '3.7'

services:
  exceptionless:
    image: exceptionless/exceptionless:latest
    environment:
      EX_AppMode: Production
      EX_ConnectionStrings__Storage: provider=folder;path=/app/storage
      EX_ConnectionStrings__Elasticsearch: http://elasticsearch:9200
    ports:
      - "5000:80"
    depends_on:
      - elasticsearch

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
    environment:
      discovery.type: single-node
    volumes:
      - es-data:/usr/share/elasticsearch/data

volumes:
  es-data:

Use the provided authentication keys and project tokens to send events from your PHP and client‑side JavaScript. Exceptionless supports grouping, dashboards and notifications similar to Sentry.

Errbit

Errbit is an open‑source error catcher compatible with the Airbrake and Hoptoad API. Many languages, including PHP, have Airbrake‑style clients, and some JavaScript libraries can send errors in that format as well.

Errbit is Ruby‑based and can be deployed with Passenger, Puma or via Docker. For many teams, it is attractive because it is relatively lightweight and easy to run on a modest VPS if traffic is not huge.

Where centralised logging fits in

Error trackers are for structured exception events. They are not a full replacement for logs. In practice, most mature setups combine:

• An error tracker (Sentry, GlitchTip, Exceptionless, Errbit, …) for exceptions and front‑end errors.
• A central log stack (ELK, Loki, etc.) to store web server logs, application logs, database logs and security logs.

If you are already thinking about multiple services and VPS nodes, it is worth reading our article on centralising logs for multiple servers with ELK and Loki. Error tracking fits naturally into that wider observability picture.

Integrating Error Tracking with Metrics and Alerts

Once PHP and JavaScript errors are flowing into your tracker, the next step is making sure they actually trigger useful actions instead of just filling a dashboard.

Creating meaningful alert rules

A few practical alert patterns:

• New error type in production: Notify the team when a brand‑new exception appears.
• Error spike: Alert when the rate of a specific error exceeds a threshold over X minutes.
• Regression after release: Alert if an error that was previously resolved reappears in the latest release.

Most platforms let you send alerts to email, chat or generic webhooks. You can also integrate with Prometheus/Grafana alerting by converting error rates into metrics. If you are building a more complete monitoring stack, see our guide on VPS monitoring and alerts with Prometheus and Grafana.

Correlating errors with logs and server metrics

When debugging a complex incident, you often need to move between three views:

• Error event: Stack trace, user, URL, environment.
• Logs: Application log lines and web server logs around the same timestamp.
• Metrics: CPU, RAM, disk I/O, database latency at that time.

By standardising on request IDs or correlation IDs and logging them consistently, you can:

• Include the request ID as a tag in your error events.
• Write the same ID into your PHP logs and Nginx/Apache logs.
• Search across logs and error tracker with that ID when debugging.

This style of observability is especially helpful for larger stores and apps where performance issues and errors interact. For example, our article on MySQL indexing and query optimisation for WooCommerce shows how database bottlenecks and PHP errors often appear together.

Security, Privacy and Compliance for Error Tracking on a VPS

Error tracking systems can easily collect more data than you actually need. That can be a risk in terms of privacy regulations and security.

Minimising sensitive data

Good practices include:

• Masking: Use built‑in data scrubbing to strip or anonymise fields like cookies, session IDs, credit card numbers, emails, etc.
• Selective context: Do not send full request bodies (especially for POST/PUT) unless necessary; if you do, mask known sensitive keys.
• User identifiers: Prefer internal user IDs or hashed identifiers over raw emails or phone numbers.

Review your error payloads by inspecting events within your tracker and adjust scrubbing rules until you are comfortable with what is stored.

Access control and retention

Because your error tracker contains internal application details and sometimes personal data, you should:

• Enforce strong authentication (MFA where possible) for the web UI.
• Limit who can access which projects, especially in multi‑tenant agency setups.
• Set sane data retention (for example 30–90 days) rather than keeping everything forever.
• Include the error tracker in your overall backup, DR and off‑site backup strategy.

All of this should fit into your broader compliance and retention plan; if you do not yet have one, our article on log retention on hosting and email infrastructure for KVKK/GDPR gives a practical starting point that applies to error events as well.

A Practical Rollout Plan for Small Teams

It is tempting to try to instrument everything at once. In practice, it works better to roll out error tracking gradually and improve as you go.

Step 1 – Start with PHP in production

• Pick a tool: Sentry (hosted or self‑hosted), GlitchTip, Exceptionless, etc.
• Install the PHP SDK in your main application.
• Wire your global exception handler to capture errors.
• Confirm that test exceptions appear in your dashboard.

Step 2 – Add browser JavaScript tracking

• Install the JS/browser SDK and configure it with DSN, environment and release.
• Generate and upload source maps if you use a bundler.
• Trigger a deliberate error in the browser and verify the event groups correctly.

Step 3 – Introduce alerts and triage workflow

• Define what should send alerts (new errors, spikes, specific endpoints).
• Connect alerts to your team’s communication channel or ticketing system.
• Establish a routine: who triages, when, and how you mark issues as resolved.

Step 4 – Integrate with logs and monitoring

• Standardise on a request ID or correlation ID across PHP, Nginx/Apache and your error tracker.
• Set up central logging (ELK, Loki) if you run multiple services.
• Connect error rates to your metrics stack (Prometheus/Grafana) for SLOs and reliability dashboards.

Step 5 – Harden security and privacy

• Review the data being stored in events and tighten scrubbing rules.
• Lock down your VPS following our VPS security hardening checklist.
• Integrate error tracking into your backup and disaster recovery tests.

Conclusion: A Calm, Observable Stack for PHP and JavaScript on a VPS

Modern PHP and JavaScript applications are too complex to debug purely from scattered log files and user screenshots. A dedicated error tracking layer – whether Sentry or an open‑source alternative on your VPS – gives you structured events, grouping, trends and alerts that turn vague “it is broken” complaints into actionable stack traces.

Start simple: capture PHP exceptions in production, then add browser/SPA error tracking. Once events are flowing, add meaningful alert rules, tie everything into centralised logs and metrics, and harden the security of your tracking stack. With a well‑sized VPS from dchost.com, fast storage and a sensible retention policy, you can run your own error tracking platform alongside your apps without drama.

If you would like help choosing the right VPS resources or planning where error tracking fits into your wider architecture (staging/production separation, backups, observability), our team at dchost.com works with these patterns every day. Reach out, and we can design a calm, reliable stack tailored to your PHP and JavaScript applications.