Drag your client folder into the browser. EasyPatcher finds what changed, ships it at about half the size, and serves the patch from your own CDN domain.
cdn-aurora.easypatcher.com
v1.4.2
C:\aurora\client\
pack/textureset.eix
queued412 MB
pack/model_00.epk
queued88 MB
bin/metin2client.exe
queued12 MB
locale/ui.msa
queued3 MB
pack/sound.eix
queued51 MB
~50%
smaller downloads after compression
0 bytes
moved for files that didn't change
1 click
to roll back to any kept version
Global edge
patches cached close to your players
Only what changed leaves your machine, at about half the size, and the patch spreads to the edge behind your own CDN domain. Not one byte moves for a file that didn't change.
compared to the live version
4,812 · 566 MB
only what changed
3 · 12 MB → 6.1 MB
cached at the edge
cache-control: immutable
cdn-aurora.easypatcher.com
v1.4.2
eu-central
eu-south
eu-north
na-east
sa-east
ap-south
Patch files are immutable by construction — repeat downloads are served from the edge and never touch origin.
0 bytes for an unchanged file: a player only ever downloads what is genuinely different.
The live version is a pointer — rolling back changes the pointer, not the upload.
Every release is the same sequence of manual steps, and every step is a place to get it wrong.
Shipping a patch today
~40 minEdit patcher.ini by hand and hope every key is spelled right.
Run a CLI tool to checksum and compress every file, every build.
Upload the whole directory tree over FTP and wait.
Rebuild and re-sign the exe when the branding changes.
Find out the patch was stale from a player's bug report.
Shipping a patch with EasyPatcher
~3 minSet every config key in a form that lists the valid values.
Drop the folder — the changed files are found and packed for you.
Only new and changed files ever leave your machine.
Branding is remote config — no rebuild, no redownload.
The version in your own storage is the single source of truth.
From dropping a folder to players receiving the patch.
1
Point the browser at the folder you would normally FTP. Nothing uploads yet — EasyPatcher reads it first.
C:\aurora\client\2
EasyPatcher compares the folder against the live version and packs only the files that differ, taking roughly half the size off each. A folder with thousands of files is handled without the tab ever locking up.
4,812 → 3 · 12 MB → 6.1 MB3
Publish the version and players pick it up on next launch. Wrong build? Point the live version back — the old one never went anywhere.
live → v1.4.2The fields on the right are the real config keys the exe reads. Change one — the window on the left updates instantly. No rebuild, no redownload.
Aurora Online — Patcher
background artwork
1200 × 420 · from remote config
Aurora Online
Server news
12.07
New zone: Glacier Valley is live.
09.07
Server maintenance complete.
bin/metin2client.exe
6.1 MB / 6.1 MB
Client up to date · v1.4.2
patcher.conf
Saved
WindowTitle
PatcherName
AccentColor
ShowPatchNotes
BinaryName
metin2client.exe
crcversion
1.4.2
These keys are written to the remote config at your storage root. The exe re-reads it on every launch with a short timeout and a cached fallback.
The pieces a self-hosted patcher makes you assemble yourself, already wired together.
Drop a folder, get a patch. Files go from the browser straight into your own storage — patch bytes never pass through our API.
Every client ships the identical signed Patcher.exe plus a two-line config. Nothing about your setup needs a C# build or a per-client signature.
Logo, background, video, icon, window title and feature flags are form fields. They land in remote config, so players see the change without redownloading anything.
Keep several patch versions live at once. Which one players receive is one dropdown, so a bad build is a rollback instead of an incident.
Storage, ingress and egress per day in the panel. Going over quota fails the upload with your real numbers — patches already live keep serving.
Each account gets isolated storage behind its own subdomain — yourserver.easypatcher.com. Patch files are immutable by construction, so repeat downloads are served from the edge and never touch origin.
cdn-aurora.easypatcher.com
GET /v1.4.2/bin/metin2client.exe
200
x-cache
HIT
age
18342
cache-control
immutable
A full client folder is thousands of files. The queue stays readable the whole way through, retries individual failures on their own, and never redoes work on a file that already landed.
Smooth progress even at 4,812 files
A failed file retries on its own
A finished file is never done twice
pack/textureset.eix
412 MB
unchanged — 0 bytes
pack/model_00.epk
88 MB
sent
bin/metin2client.exe
12 MB
locale/ui.msa
3 MB
unchanged — 0 bytes
pack/sound.eix
51 MB
unchanged — 0 bytes
You move without breaking a working setup: your old patcher keeps serving until you switch it off yourself.
Read the migration guide01
EasyPatcher takes the first version as the baseline. You don't have to restructure what's on FTP.
02
The single signed exe goes to everyone; the only per-client part is one config line.
03
Turn it off once players have moved. Both systems can run in parallel — no downtime needed.
Every operation resolves the storage from your session — never from anything the browser sends.
The browser writes straight into your storage; we only ever know the manifest.
New uploads are refused; patches already live keep serving.
Storage. No per-seat pricing, no bandwidth surprises.
/month
100 MB of patch storage
2 patch versions kept
1 publish per day
Drag-and-drop patching
/month
2 GB of patch storage
5 patch versions kept
Unlimited publishes
Drag-and-drop patching
/month
4 GB of patch storage
10 patch versions kept
Unlimited publishes
Drag-and-drop patching
/month
10 GB of patch storage
Unlimited patch versions kept
Unlimited publishes
Priority support
Files are compressed before they are uploaded, which takes roughly half the size off typical game binaries — measured at 50% on a 12 MB executable. Skipping unchanged files is the bigger win on top of that: files that didn't change transfer nothing at all, so a rebuild touching ten files costs ten compressed files, not a whole client folder.
No. Every client runs the identical signed Patcher.exe. The only per-client file is a config whose one meaningful line points at your hosted config, which the exe fetches at startup and overlays over its local copy.
New uploads are refused before they start, with your current usage and your tier limit in the error. Everything already in your storage keeps serving — we do not break a live game client over billing.
No. Branding lives in the remote config at your storage root, which the exe re-reads on every launch with a short timeout and a cached fallback — so a network problem can never strand a client on a broken config.
Each patch version is its own immutable folder, and the live version is a pointer. Change the pointer and the next launch picks it up. No re-upload, no downtime, nothing deleted.
Each account gets its own isolated storage, and every operation resolves it from your signed-in session — never from anything the browser sends. There is no request shape that reaches another account's data.
Yes — 100 MB, two versions kept and one publish per day, served from a shared EasyPatcher subdomain instead of your own custom domain. Enough to wire the whole flow end to end before you pay anything.
Create an account, drop a folder, and watch only the changed files move.
No credit card · 100 MB free · set up in minutes