CS2 case farming automation.

An automated CS2 farm is a pipeline, not a single click. Each VM has a recurring job spec: when to start, how long to play, when to collect, what to alert on. The panel is the runner; you are only the editor of the spec.

• Per-account scheduled session windows

  Each VM runs on its own clock. Define shift length, start time, and randomization per account.

• Auto-relaunch on crash

  A watchdog process restarts CS2 and re-enters the match when a session drops.

• Auto-collect drops and rank rewards

  Weekly case drops and end-of-rank rewards are claimed the moment they become eligible.

• Daily summary to Telegram

  One scheduled message with per-VM uptime, drops collected, and any anomalies.

• Ban-detection auto-pause

  If Steam flags an account, the panel stops the VM and alerts you instead of grinding into a banned session.

The point of scheduling is not just convenience. Cadence and randomization are part of the safety model. Real players do not log in at the same second on every account, run for the same duration, and log out together. A botnet does. The schedule is where you make a fleet of farm accounts look like a group of human players who happen to share a household IP.

Operators typically configure each VM with a shift length of two to four hours, a randomized start offset of fifteen to ninety minutes, and a weekly window aligned to the Wednesday drop reset so each account is online when its drop becomes eligible. Days off are normal. Some VMs run five sessions a week, some run two. You can also stagger across time zones: accounts that have historically played in EU evening hours stay on that pattern after they join the farm.

The anti-pattern is running every VM 24/7 in lockstep. It looks exactly like what it is: a fleet of automated processes on a single host. Schedule variance is free and it changes the detection surface significantly. The 5 mistakes article covers cadence mistakes in depth.

Automation is only as useful as its observability layer. The Telegram mini-app is both: it accepts commands and emits alerts, so the farm reaches you and you reach the farm without sitting at the host. Most operators check it on a phone, with the host in another room or another building.

Triggers fall into two buckets: outbound commands you send to the panel, and inbound alerts the panel sends to you. Together they make the farm a system you operate by exception.

• Start, stop, status

  Run the farm, pause everything, or pull a live snapshot from anywhere.

• Per-VM restart

  Restart a single VM without touching the rest of the fleet.

• Ban-detected alarm

  The moment Steam flags an account, the VM auto-pauses and you get a push notification.

• Drop collected pings

  Optional per-VM pings on weekly drop pickup. Off by default to keep your chat quiet.

Things break. CS2 crashes mid-match. Steam pushes an unscheduled update. A VM locks under disk pressure. A session times out. A real farm has to survive all of it without you watching. The recovery layer is a small watchdog that runs alongside the panel and acts on a strict order of operations: detect the failure, try to recover the same VM in place, retry up to a threshold, then escalate.

For a CS2 crash the watchdog relaunches the client, re-authenticates the Steam session, and rejoins the configured game mode. For a locked VM it issues a controlled reboot and waits for the boot sequence to complete before re-running the schedule. For a Steam update the panel pauses the VM until the new client finishes installing, then resumes. If a recovery threshold is hit the VM goes into a failed state and the Telegram alert flags it for you. The no-babysit promise is honest: most days you do nothing. Some weeks something breaks and you decide whether to retire an account or rotate it.

When you do check in, you should not have to dig. The panel dashboard shows the whole fleet on one screen, sorted by health. Per-VM you see live CPU, RAM, and GPU readings, last-drop timestamp, current map, walkbot health, and the last ten error log lines. Green means running on schedule; amber means recovering; red means failed and waiting on you.

The host-side resource readout matters because the bottleneck for most operators is hardware, not software. If you see GPU utilization pinned at 99 percent across every VM, you are saturated and adding accounts will only degrade behavior. The dashboard is built so that decision takes one glance, not a spreadsheet.

End-to-end, most operators are running their first scheduled VM in under ninety minutes. The longest step is GPU partitioning, which you do once per host. Everything after that is filling in fields.

1. Install the Windows software

   Install the Windows software on a Pro, Enterprise, or Education host with virtualization enabled in BIOS. The installer checks for Hyper-V support and prompts if anything is missing.

2. Provision Hyper-V VMs

   Create one VM per Steam account using the Hyper-V VM setup guide. Each VM gets a partitioned GPU and a distinct hardware fingerprint so Steam sees a separate machine per account.

3. Add Steam accounts via maFile

   Attach each Steam account to its VM with the maFile. The panel handles login on every scheduled session and never asks you to share passwords in plain text outside the panel itself.

4. Configure session schedules

   Per VM, set shift length, randomized start offset, and weekly cadence. Stagger across time zones if your accounts have a history of playing on different schedules. Save once; the runner takes it from there.

5. Connect Telegram and walk away

   Link the Telegram mini-app with one tap. Pick which alerts you want on by default. Confirm a test message arrives, then close the host and let the schedule run.