Miningcore Setup for SHA256 Pools — Production Deployment Guide
Miningcore is a high-performance open-source pool engine on .NET. This page is a practical guide to deploying it for SHA256/SHA256d coins: architecture, configuration boundaries, payout safety, and the checks we run before a public launch.
Why operators choose Miningcore for SHA256 pools
Miningcore is a strong match when you want a clean separation between public Stratum traffic and internal accounting, and when you prefer an API-driven operational model over a monolithic web app.
- Multi-coin operations: Run separate pools per coin with explicit config boundaries and shared observability.
- Metrics-first ops: Expose stats and health signals to your own dashboards and alerting pipelines.
- Performance headroom: Efficient share processing with predictable scaling as hashrate grows.
- Extensibility: Add custom payout logic, reporting, or business rules without patching a legacy stack.
If you want a batteries-included website quickly, Yiimp is often the fastest path. If you want a service-style stack with strong config hygiene and .NET maintainability, Miningcore is usually the better long-term option.
Reference architecture: separate edge, core, nodes, and data
A stable pool is a system. It must continue working when miners reconnect in bursts, when nodes restart, and when disks fill. The architecture below is the baseline we deploy for production pools.
- Stratum edge: Public TCP/TLS endpoints with rate limits, VarDiff (variable difficulty), and DDoS-aware networking.
- Pool core: Share validation + block handling + accounting, isolated from the public edge where possible.
- Database layer: Durable persistence (often Postgres) with tuned parameters and tested restores.
- Coin nodes: Full nodes with pinned versions, private RPC, and monitored sync state.
- Ops tooling: Logs, metrics, alerting, and a runbook that starts with “what to check first.”
For public pools, we typically separate edge and core roles, and we ensure metrics are available before launch so incidents are diagnosable.
Miningcore deployment configuration: what we touch and test
Your exact configuration depends on coin(s), payout model, expected hashrate, and whether you need regional endpoints. In most engagements, we cover:
- Miningcore service config: Pool definitions, payout settings, wallet/RPC connections, and worker/ban policies.
- Node integration: RPC credentials, template validation, and restart-safe node services per coin.
- VarDiff and share processing: Difficulty bands matched to ASIC share rates and marketplace behavior.
- Payments and audit logs: Idempotent payout jobs, batching, and metadata required for dispute resolution.
- Monitoring and alerts: Dashboards for rejects, latency, orphan rate, and payout job status.
- Security baseline: Least-privilege database users, secret storage, firewall rules, and backup/restore drills.
We keep changes versioned and reproducible. Operators should be able to rebuild the deployment from documented configs, not tribal knowledge.
Stratum endpoints: what miners connect to
Miners should see a small set of endpoints: primary TCP, optional TLS, and (if you support it) a separate port profile for marketplace hashpower. Keep the docs consistent with your authentication scheme.
stratum+tcp://POOL-DOMAIN:3333
stratum+tcp://POOL-DOMAIN:443
stratum+ssl://POOL-DOMAIN:3443We provide copy/paste examples for common ASIC firmware and a troubleshooting section for common reject codes.
Failure modes we design around
- Node drift: A node can be “running” but not synced; we alert on height lag and IBD state.
- Wallet RPC stalls: Payout runners must handle slow RPC without duplicating payments.
- Database growth: Share tables grow fast; we size storage, tune indexes, and add pruning plans.
- Reconnect storms: Marketplaces and proxies can churn connections; we enforce throttles and caps.
- Configuration sprawl: Multiple coins and ports require config hygiene; we keep templates and validation tests.
Most outages are predictable. We design around these failure modes and make them observable so operators can react quickly. For deeper hardening guidance, see Mining pool security hardening.
Handover artifacts your team should receive
- Versioned pool configurations with comments and identifiers for rollback.
- Service management notes: start/stop, upgrades, rollback steps, and log locations.
- Backup + restore evidence (what was restored, when, and the outcome).
- Node inventory: daemon versions, data paths, RPC endpoints, and wallet handling procedure.
- Monitoring checklist: dashboards, alert thresholds, and on-call escalation steps.
- First-incident playbook for common failures (node down, DB full, Stratum flood).
Engagement scope: build, validate, and support
If you don’t want to assemble the stack yourself, we offer turnkey deployments and ongoing operations support.
- Design and sizing: Choose a layout that matches expected hashrate, miner count, and growth.
- Implementation: Install/configure Miningcore, coin nodes, database, and monitoring; validate end-to-end.
- Launch execution: Publish miner docs, test payouts, and run a controlled soft launch before opening wide.
- Ops support: Upgrades, troubleshooting, performance tuning, and security maintenance.
Miningcore can run SHA256 coins beyond BTC. For coin-specific Bitcoin Cash notes and a launch checklist, see the BCH setup page. Bitcoin Cash (BCH) mining pool setup.
Miningcore Q&A for operators
Can you deploy Miningcore for BTC, BCH, and other SHA256 coins?
Yes. We deploy the required full nodes, wire private RPC, and configure pool definitions per coin. Exact settings depend on the chain implementation and your payout design.
What pool types do you support with Miningcore?
We support solo pools, private pools with restricted access, and public pools with strong anti-abuse controls and clear miner onboarding.
Will NiceHash or rental hashpower work on Miningcore?
Often yes. We tune VarDiff, connection limits, and job timing for marketplace behavior and test against nonstandard clients when required.
Do you build a web UI or only the API?
Both are possible. Some operators run an API-only deployment feeding their own UI, while others want a branded miner portal with workers, payouts, and charts.
How do you handle upgrades safely on a production Miningcore pool?
We pin versions, stage changes, run validation tests, and keep rollback steps documented. The goal is to make upgrades routine instead of risky.
What details matter most for a Miningcore quote?
Coin list, expected hashrate now and in the next few months, pool type, payout model, regions, and whether you need a full website or an API-first deployment.
Is Miningcore open source and should I rely on random “installer bundles”?
Miningcore is generally used as open source. For bundled forks or “one-click” installers, we recommend reviewing maintenance history and diffs, then deploying with reproducible builds and rollback plans.
Can I run a real Miningcore pool on Windows?
Windows can be fine for development, but production pools are typically deployed on Linux for stability, networking tools, and automation.
What does “Miningcore Pro” usually mean?
It usually refers to a fork or a managed variant rather than the upstream project. Treat it like any third-party build: review code provenance, security posture, and update cadence before trusting it in production.
Ready to deploy Miningcore? Contact us with your target coins, hashrate, and payout model. Contact us.