Self-Hosted GitLab and Jira on a VPS: Resource Planning and Security

Running your own GitLab, Jira and related DevOps tools on a VPS gives you full control over code, issues, CI/CD and compliance. But it also turns your team into a mini hosting provider: you now own capacity planning, storage growth, backups and security hardening. In practice, most problems we see are not about installing GitLab or Jira themselves, but about undersized VPS plans, missing backups or weak security defaults. In this guide, we’ll walk through how we at dchost.com think about sizing and securing a VPS when customers want a self-hosted DevOps stack. You’ll see realistic resource estimates for different team sizes, example architectures (single VPS vs multiple servers), concrete security steps and how to avoid common bottlenecks around RAM, disk I/O and CI pipelines. The goal is simple: by the end, you should know what kind of VPS (or dedicated server) you actually need, how to structure your GitLab/Jira stack and which hardening steps to apply from day one.

Why Self-Host GitLab, Jira and DevOps Tools on a VPS?

Control and Compliance

Many teams move Git hosting, issue tracking and CI/CD in-house because they need strict control over data location, retention and access. With a VPS or dedicated server from dchost.com, you decide which data center region to use, how long logs are stored, which backups exist and who has low-level root access. That’s often essential for clients under strict contracts, industry regulations or KVKK/GDPR obligations.

Integration Freedom

Self-hosted GitLab and Jira are often the heart of a larger DevOps ecosystem:

• Git repositories and merge requests in GitLab
• Issue tracking and project management in Jira
• GitLab CI runners or other CI agents building and testing code
• Container registry, artifact repositories and package registries
• Monitoring, logging, VPN and internal dashboards

On your own VPS you can tune every component: custom runners, caching layers, reverse proxies, WAF rules, private networks between services and custom backup flows. You’re not limited to a fixed SaaS feature set.

Predictable Long-Term Cost

When your team grows, per-user SaaS pricing for Git and issue tracking can climb quickly. A well-sized VPS or dedicated server often becomes more cost-effective once you cross a certain number of users or CI minutes. The key is to right-size resources and keep an eye on memory, disk and CPU utilisation. Our guide to managing RAM, swap and the OOM killer on VPS servers explains how to track and tune memory usage so you don’t pay for idle capacity—or crash under load.

Capacity Planning: How Big Should Your VPS Be?

Let’s break down what typically runs on a self-hosted DevOps stack and how that translates into CPU, RAM and storage needs.

Key Components and Their Resource Profiles

• GitLab core (web, API, background workers): Ruby and Go services; memory-hungry, benefits from multiple vCPUs and fast SSD/NVMe.
• GitLab database (PostgreSQL): latency-sensitive, prefers dedicated RAM and low disk latency.
• GitLab Redis: used for caching and queues; relatively small but needs low latency.
• Jira application: Java-based; JVM heap + OS memory; can grow significantly with plugins and users.
• Jira database (PostgreSQL, MySQL/MariaDB): similar to GitLab DB considerations.
• CI runners (Docker-in-Docker, shell or Kubernetes runners): CPU- and RAM-intensive; each job eats resources for the build duration.
• Container registry / artifact storage: I/O- and disk-capacity heavy; needs good throughput and a clear retention policy.
• Reverse proxy (Nginx, Traefik, HAProxy): lightweight but critical for SSL/TLS and routing.

Scenario 1: Small Team (3–10 Developers)

For a small team with modest projects, a single well-sized VPS is realistic if you plan for growth. A typical stack:

• GitLab (omnibus or containerised) with integrated PostgreSQL/Redis
• Jira on the same VPS, using the same or a separate database instance
• 1–2 GitLab CI runners (shell or Docker) on the same machine

Recommended baseline:

• vCPU: 6–8 vCPU
• RAM: 16–24 GB
• Disk: 300–500 GB NVMe/SSD (fast IOPS is more important than raw capacity)
• Bandwidth: At least a few TB/month, depending on how often developers push/pull large repos and artifacts.

This gives room for GitLab, Jira and a couple of concurrent CI jobs. If you run many builds with Docker, lean toward the higher end of RAM and vCPU. Using containers for each service as described in our guide to running isolated Docker containers on a VPS helps you keep resource limits per service under control.

Scenario 2: Growing Team (10–40 Developers)

Once you cross ~10 active developers with regular CI usage, a monolithic single VPS quickly becomes tight. At this point we usually recommend:

• VPS A (Core services): GitLab + PostgreSQL + Redis + Jira application (no CI runners)
• VPS B (CI runners): One or more VPS instances dedicated to GitLab runners

Baseline sizes:

• VPS A: 8–12 vCPU, 24–32 GB RAM, 500–750 GB NVMe/SSD
• CI VPS (per 4–6 concurrent jobs): 4–8 vCPU, 8–16 GB RAM, 200–300 GB SSD for temporary build artifacts

Separating CI runners keeps your core Git and Jira experience responsive even when multiple pipelines run in parallel. It also simplifies future scaling: you can just add more CI VPS instances as your pipeline load grows, without touching the main GitLab/Jira node.

Scenario 3: Larger Setup (40+ Developers or Heavy CI)

For larger teams or heavy continuous integration, think in terms of roles rather than one big server:

• GitLab application node(s)
• Dedicated PostgreSQL database server
• Dedicated Redis
• Jira application server (possibly more than one, behind a load balancer)
• Multiple CI runner nodes
• Optional: separate server for container registry and artifact storage

This can be built with larger VPS plans or a mix of VPS and dedicated servers. Use fast NVMe disks for Git and database servers, and allow hundreds of GB or even TB for container images and artifacts, with lifecycle policies to prune old data.

Plan for Memory, Not Just CPU

GitLab, Jira and databases will use significant RAM. Starved memory leads to swapping, slow builds and even crashes. We strongly recommend enabling swap carefully and monitoring usage, as explained in our detailed guide on RAM, swap and the OOM killer for VPS servers. Aim for:

• Enough RAM for core services to run without swapping during normal load
• Swap as a “safety net”, not a permanent extension of RAM
• Alerts when memory pressure or swap usage crosses thresholds

Architecture Choices: One VPS or Multiple Servers?

Single VPS: When It Works

A single VPS hosting GitLab, Jira, the database and a couple of runners can be perfectly fine if:

• You have a small team and low CI concurrency
• You can tolerate some maintenance windows during upgrades
• You keep good off-site backups and snapshots

The main advantage is simplicity: one machine to secure, one backup strategy, one bill. For small agencies or start-ups just formalising their DevOps stack, this is a pragmatic first step.

Separate CI Runners Early

Even for small teams, we often advise moving CI runners to a second VPS earlier than you think. CI jobs are bursty and resource-hungry; building a large Docker image or running end-to-end tests can temporarily consume a huge chunk of CPU and RAM. Isolating runners stops those spikes from slowing down Git pushes, code browsing and Jira issue operations.

Dev, Staging and Production Environments

Some teams run “internal staging” instances of GitLab or Jira for plugin testing, upgrades and major configuration changes. Others use a single production instance but separate environments for hosted applications. Our article on hosting architecture for development, staging and production environments explains the trade-offs between one big server and multiple VPS setups. The same principles apply to your DevOps tooling: staging instances reduce upgrade risk but add operational overhead.

When a Dedicated Server or Colocation Makes Sense

If you have dozens of developers, heavy CI/load testing and very large repositories, a single powerful dedicated server or colocated machine may become more economical and predictable. You get guaranteed physical CPU cores, dedicated NVMe disks and, if needed, hardware RAID. At dchost.com we often see this as a natural evolution: teams start on a VPS, then migrate GitLab/Jira to a dedicated node while keeping elastic CI runners on VPS instances.

Security Hardening for GitLab, Jira and DevOps Stacks

GitLab and Jira hold your source code, credentials, access tokens and infrastructure secrets. Treat this VPS like a crown jewel. Security is a layered exercise: operating system, network, application and identity.

1. OS and SSH Hardening

Before you even install GitLab or Jira, lock down the server:

• Keep the OS up to date (unattended upgrades or a regular patch schedule).
• Disable direct root SSH login; use a non-root user with sudo.
• Use SSH keys instead of passwords; consider FIDO2 or hardware keys for admins.
• Change the default SSH port only as a minor nuisance barrier, not a real defence.
• Install Fail2ban or similar to block brute-force attempts.

Our VPS security hardening checklist walks through sshd_config, Fail2ban, automatic updates and disabling root SSH in detail. Use it as a step-by-step baseline for every DevOps VPS.

2. Firewall and Network Segmentation

At minimum, only expose the ports you actually need:

• HTTP/HTTPS (80/443) for web access, ideally behind a reverse proxy and WAF
• SSH (for admin access), restricted by IP if possible
• Database ports accessible only from trusted internal IPs (CI runner nodes, staging nodes, VPN ranges)

Use the OS firewall (ufw, firewalld or raw iptables/nftables) to enforce this. Our article on firewall configuration on VPS servers shows concrete ufw and firewalld examples that you can adapt for GitLab and Jira nodes.

For larger setups, consider placing GitLab/Jira behind a reverse proxy or WAF (Nginx, HAProxy, ModSecurity, Cloudflare, etc.) for additional protection: rate limiting, IP allowlists, basic bot filtering and TLS termination.

3. TLS/SSL and HTTP Security Headers

All access to GitLab and Jira should be over HTTPS. Use strong TLS configuration, disable old protocols and ciphers, and set HSTS once you’re confident the site will always be HTTPS-only. Complement this with modern HTTP security headers (Content-Security-Policy, X-Frame-Options, Referrer-Policy, etc.) to reduce attack surface from browsers.

dchost.com’s blog has multiple deep dives on HTTP security headers and keeping TLS configurations secure on real-world servers; consider following those patterns for your DevOps endpoints as well.

4. Application-Level Security

Inside GitLab and Jira themselves, review:

• Authentication: Enforce strong passwords, 2FA for admins and ideally SSO (SAML/OIDC) with your identity provider.
• Access control: Use groups, project permissions and roles; avoid everyone having Owner/Admin access.
• Tokens and secrets: Limit personal access tokens and CI tokens; set expiries and rotate regularly.
• Webhooks and integrations: Restrict webhooks to trusted destinations; use secret tokens to verify callbacks.
• Plugins (especially in Jira): Only install well-maintained, necessary add-ons and keep them updated.

5. Logs, Monitoring and Alerts

Self-hosting means you’re also responsible for noticing when something breaks or gets attacked. At a minimum:

• Collect system logs (auth, kernel, firewall) and application logs (GitLab, Jira, Nginx).
• Monitor CPU, RAM, disk usage, I/O wait and network throughput.
• Set alerts for unusual login patterns, repeated 500 errors or sudden spikes in 4xx/5xx responses.

If you centralise logs across multiple VPS servers, GitLab can emit structured logs to a logging stack (Loki, ELK, etc.). Our guide on centralising logs for multiple servers is a good starting point for a multi-node DevOps environment.

Storage, Backups and Disaster Recovery

Understand Your Storage Growth

GitLab and Jira storage usage tends to grow in bursts:

• New repositories and forks
• Binary artifacts, build logs and test reports
• Docker images in the container registry
• Attachments in Jira issues (screenshots, docs, logs, exports)

Plan not only for today’s disk usage but for 12–24 months ahead. Fast NVMe storage makes a huge difference for Git operations and database queries, especially under CI load. For large artifact and image storage, you can combine local NVMe for hot data with object storage for archived artifacts.

Backup Strategy: More Than Snapshots

Snapshots at the VPS level are useful, but they are not enough on their own. For GitLab and Jira you should have:

• Database backups: Regular PostgreSQL/MariaDB backups with a tested restore process.
• Application backups: Git repositories, config files, attachments, CI configuration and registries.
• Off-site copies: Stored in a different environment or object storage, with encryption.

If you already use S3-compatible object storage, tools like rclone or restic make automated off-site backups straightforward. Our article on automating off-site backups to object storage with rclone, restic and cron shows how to build a robust, versioned backup pipeline that also works nicely for GitLab and Jira data.

RPO/RTO for DevOps Tools

Define clear objectives:

• RPO (Recovery Point Objective): How much data can you afford to lose? For Git and tickets, most teams aim for at most a few hours.
• RTO (Recovery Time Objective): How long can Git/Jira be offline? For active teams, more than a few hours can halt development.

These numbers dictate how often you run backups and how you design recovery. For example, if you need short RTO, you might keep a warm standby VPS with restored backups that can be promoted quickly.

Running GitLab and Jira with Containers on a VPS

Many teams prefer to run GitLab, Jira and supporting services with Docker or container runtimes to gain isolation and easier upgrades.

Benefits of Containerising Your DevOps Stack

• Isolation: Resource limits per container stop one service from consuming all CPU/RAM.
• Reproducibility: The same Docker images can run in staging and production.
• Easier upgrades: Roll back to a previous image if needed.
• Cleaner host OS: Fewer system packages installed directly on the VPS.

However, containerisation doesn’t remove the need for VPS hardening. You still must secure SSH, firewalls, backups and the host kernel. Our tutorial on running isolated Docker containers on a VPS is a good reference if you plan to containerise GitLab, Jira, PostgreSQL and Redis on one or more servers.

Where CI Runners Should Live

GitLab runners are excellent candidates for containers: they are stateless, easy to scale and often ephemeral. You can run Docker-in-Docker runners inside their own containers on separate VPS nodes, with autoscaling based on the number of queued jobs. Just remember that each CI job’s container still consumes host resources, so plan vCPU and RAM accordingly on runner nodes.

Bringing It All Together (and How dchost.com Fits In)

Designing a stable home for GitLab, Jira and your DevOps tools on a VPS is mostly about being intentional: know your team size, CI workload, growth expectations and security requirements. Start by sizing a core VPS (or dedicated server) for GitLab and Jira with fast NVMe storage and enough RAM. Decide early whether CI runners stay on the same node or move to separate VPS servers. Lock down the host with solid SSH, firewall and update policies, following our first 24 hours on a new VPS checklist and the VPS security hardening guide. Then put serious thought into backups and recovery, using off-site object storage where appropriate.

At dchost.com we provide the underlying building blocks—VPS plans with NVMe storage, dedicated servers and colocation options—so you can choose the architecture that fits your DevOps workflow today and can grow tomorrow. If you’re unsure whether to start with a single powerful VPS or a small cluster of specialised nodes, reach out with your team size, CI needs and compliance constraints; we’ll help you map that into a concrete resource plan and a security baseline you can actually maintain.