Self-Hosting

Options and considerations for self-hosting Upptime beyond GitHub

Self-Hosting Overview

While Upptime is designed to run entirely on GitHub’s infrastructure, you can self-host various components for increased control, privacy, or custom requirements.

What Can Be Self-Hosted

Upptime consists of several independent components:

Status Page (Static Site)

The status page is a static Svelte site generated by GitHub Actions and deployed to GitHub Pages. You can host it anywhere that serves static files.

Generated location: site/status-page/__sapper__/export/

Self-hosting options:

• Netlify
• Vercel
• Cloudflare Pages
• AWS S3 + CloudFront
• Your own web server

Monitoring Checks

Uptime checks run as GitHub Actions workflows every 5 minutes (configurable). You can run these on your own infrastructure.

Self-hosting options:

• Self-hosted GitHub Actions runners
• Custom cron jobs using the Upptime CLI
• GitLab CI/CD
• Jenkins or other CI systems

Data Storage

By default, all data is stored in the Git repository. You can store it elsewhere.

Self-hosting options:

• Self-hosted Git server (GitLab, Gitea)
• Database backend (PostgreSQL, MySQL)
• Object storage (S3, MinIO)
• Time-series database (InfluxDB, Prometheus)

Issue Tracking

Downtime incidents create GitHub Issues. You can use alternative issue trackers.

Self-hosting options:

• GitLab Issues
• Jira
• Custom webhook endpoints

Self-Hosting the Status Page

Using Netlify

Modify .github/workflows/site.yml to deploy to Netlify:

name: Static Site CI
on:
  schedule:
    - cron: "0 1 * * *"
  workflow_dispatch:

jobs:
  release:
    name: Build and deploy site
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          token: ${{ secrets.GH_PAT }}
      
      - name: Generate site
        uses: upptime/uptime-monitor@v1.41.0
        with:
          command: "site"
        env:
          GH_PAT: ${{ secrets.GH_PAT }}
      
      - name: Deploy to Netlify
        uses: nwtgck/actions-netlify@v2
        with:
          publish-dir: './site/status-page/__sapper__/export'
          production-deploy: true
        env:
          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
          NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}

Using Vercel

Add vercel.json to your repository:

{
  "buildCommand": "npm run build",
  "outputDirectory": "site/status-page/__sapper__/export",
  "framework": "svelte"
}

Modify the workflow:

- name: Deploy to Vercel
  uses: amondnet/vercel-action@v25
  with:
    vercel-token: ${{ secrets.VERCEL_TOKEN }}
    vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
    vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
    working-directory: ./site/status-page/__sapper__/export

Custom Web Server

Generate the site and deploy manually:

# In your workflow or locally
npx @upptime/uptime-monitor site

# Copy to your web server
scp -r site/status-page/__sapper__/export/* user@server:/var/www/status

Self-Hosted GitHub Actions Runners

Run monitoring checks on your own infrastructure for:

• Monitoring internal services
• Avoiding GitHub Actions usage limits
• Custom network configurations

Setup Self-Hosted Runner

1. Install the runner on your server:

# Download and extract
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux.tar.gz -L \
  https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz
tar xzf ./actions-runner-linux.tar.gz

# Configure
./config.sh --url https://github.com/{owner}/{repo} --token YOUR_TOKEN

# Install as service
sudo ./svc.sh install
sudo ./svc.sh start

2. Update workflows to use self-hosted runner:

Modify .upptimerc.yml:

workflowSchedule:
  uptime: "*/5 * * * *"

runner: self-hosted  # Use self-hosted runner

Using GitLab Instead of GitHub

Port Upptime to GitLab CI/CD:

GitLab CI Configuration

Create .gitlab-ci.yml:

stages:
  - monitor
  - build
  - deploy

variables:
  GIT_STRATEGY: clone

uptime_check:
  stage: monitor
  image: node:18
  script:
    - npm install -g @upptime/uptime-monitor
    - upptime update
  only:
    - schedules
  artifacts:
    paths:
      - history/
      - api/

build_site:
  stage: build
  image: node:18
  script:
    - upptime site
  artifacts:
    paths:
      - site/

deploy_pages:
  stage: deploy
  script:
    - echo "Deploying to GitLab Pages"
  artifacts:
    paths:
      - public
  only:
    - master

Convert Configuration

Rename .upptimerc.yml and update paths:

owner: gitlab-username
repo: upptime-gitlab
provider: gitlab  # Specify GitLab

sites:
  - name: My Service
    url: https://example.com

Custom Data Backend

Store Data in PostgreSQL

Create a custom script to replace Git storage:

// custom-backend.js
const { Pool } = require('pg');
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

async function saveMetrics(site, status, responseTime) {
  await pool.query(
    'INSERT INTO uptime_metrics (site, status, response_time, timestamp) VALUES ($1, $2, $3, NOW())',
    [site, status, responseTime]
  );
}

async function getMetrics(site, period = '7d') {
  const result = await pool.query(
    'SELECT * FROM uptime_metrics WHERE site = $1 AND timestamp > NOW() - INTERVAL $2',
    [site, period]
  );
  return result.rows;
}

module.exports = { saveMetrics, getMetrics };

Custom Workflow Integration

Modify .github/workflows/uptime.yml:

- name: Check endpoint status
  run: |
    # Run custom check
    node custom-check.js
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}

Monitoring Internal Services

Self-hosted runners can monitor services that aren’t publicly accessible:

# .upptimerc.yml
sites:
  - name: Internal API
    url: http://internal-api.local:3000
    # This will only work with self-hosted runner on same network
  
  - name: Database
    url: postgres.internal:5432
    check: "tcp-ping"

Cost Considerations

GitHub (Default)

• Free tier: 2,000 Actions minutes/month
• Pro: $4/month + usage
• Team: $4/user/month + usage
• GitHub Pages: Free

Self-Hosted

• Server costs: $5-20/month (VPS)
• Maintenance: Your time
• Bandwidth: Varies by provider
• Control: Complete

Hybrid Approach

Mix GitHub and self-hosted components:

# Use GitHub for public services
sites:
  - name: Public Website
    url: https://example.com

# Self-hosted runner for internal services  
  - name: Internal Service
    url: http://internal.local
    runner: self-hosted

Security Considerations

When self-hosting, ensure:

• Secrets are properly managed (use environment variables)
• Self-hosted runners are in secure networks
• Access tokens have minimal required permissions
• SSL/TLS is enabled for all public endpoints

Migration Path

Gradually migrate to self-hosting:

1. Start: Full GitHub setup
2. Phase 1: Self-host status page only
3. Phase 2: Add self-hosted runners for internal monitoring
4. Phase 3: Custom data backend if needed
5. Final: Fully self-hosted if required