Infrastructure Guide• 15 min read

The Complete Miningcore 2026 Production Deployment Guide.

Setting up a crypto mining pool isn't just about compiling some C# code. It's about hardening a Linux server, tuning PostgreSQL for high-frequency writes, and architecting an Nginx reverse proxy that won't buckle under DDoS attacks.

1. Introduction & Server Prerequisites

Miningcore remains the industry standard for custom pool operations, but its default configuration is meant for local testing. If you put a default config on a public IP, your API will crash within hours, and your stratum ports will be flooded.

For a production deployment supporting 1,000+ workers, you need bare minimum hardware:

  • CPU: 8-Core AMD EPYC or Intel Xeon
  • RAM: 32GB+ ECC (PostgreSQL loves RAM)
  • Storage: 1TB+ NVMe SSD (Avoid SATA SSDs due to IOPS bottlenecks)
  • OS: Ubuntu 24.04 LTS

2. Server Hardening

Before installing any dependencies, lock down your machine. Never run Miningcore as the root user. // Using a dedicated user prevents total system compromise if the stratum daemon gets exploited.

sudo adduser pooladmin sudo usermod -aG sudo pooladmin su - pooladmin

Configure UFW (Uncomplicated Firewall) immediately. Only open the ports you strictly need. If you're using Cloudflare for the frontend, only allow Cloudflare IPs to hit your API port.

sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw allow 3032:3040/tcp # Stratum ports sudo ufw enable

3. PostgreSQL Tuning for High IOPS

Miningcore generates massive amounts of data. Every share submitted by every worker is an INSERT query. Default PostgreSQL settings will choke on this.

After installing Postgres 16+, edit /etc/postgresql/16/main/postgresql.conf:

  • shared_buffers = 8GB (Set to ~25% of total RAM)
  • work_mem = 64MB
  • maintenance_work_mem = 512MB
  • effective_cache_size = 24GB (Set to ~75% of total RAM)
  • synchronous_commit = off // Hacky fix for IO lag, slightly increases data loss risk on power failure, but massive TPS boost.

Restart PostgreSQL and run the Miningcore createdb.sql scripts.

4. Compiling Miningcore

Don't use pre-compiled binaries for production. Compile it yourself using the latest .NET 8 SDK to benefit from compiler-level optimizations specific to your CPU architecture.

git clone https://github.com/oliverw/miningcore.git cd miningcore/src/Miningcore dotnet publish -c Release --framework net8.0 -o ../../build

5. The Configuration File (config.json)

This is where most people fail. A poorly structured config.json leads to orphaned blocks and payout failures.

Payment Processing

Set your payout interval to something reasonable. // Doing payouts every 5 minutes will drain your wallet in network fees. Set it to every 2-4 hours.

"paymentProcessing": { "enabled": true, "interval": 120, // 2 hours "shareRecoveryFile": "recovered-shares.txt" }

Banning Malicious Peers

Enable the banning engine. Botnets will scan your open ports and submit invalid shares.

"banning": { "manager": "Integrated", "banOnJunkReceive": true, "banOnInvalidShares": true }

6. Systemd Integration

Miningcore must be run as a service so it auto-restarts on failure. Create /etc/systemd/system/miningcore.service.

[Unit] Description=Miningcore Pool After=network.target postgresql.service [Service] Type=simple User=pooladmin WorkingDirectory=/home/pooladmin/miningcore/build ExecStart=/usr/bin/dotnet /home/pooladmin/miningcore/build/Miningcore.dll -c /home/pooladmin/miningcore/build/config.json Restart=always RestartSec=10 LimitNOFILE=100000 [Install] WantedBy=multi-user.target

7. Nginx Reverse Proxy & API Security

Never expose the Miningcore API directly. Use Nginx to proxy requests and cache responses. The API endpoint /api/pools gets hammered by frontend dashboards. Caching it for just 5 seconds drastically reduces CPU load.

proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m use_temp_path=off; server { listen 443 ssl; server_name api.yourpool.com; location /api/ { proxy_pass http://127.0.0.1:4000; proxy_cache api_cache; proxy_cache_valid 200 5s; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

8. Conclusion

A production Miningcore deployment requires a holistic understanding of Linux system administration, database tuning, and network security. By following this guide, you bypass the common pitfalls that cause 90% of new pools to shut down within their first month.