Konfiguration von go-reupper

go-reupper liest seine Einstellungen aus der Datei:

config/reupper.config.yml

Wenn du das Tool bekommst, liegt meistens eine Datei reupper.config.dist.yml dabei.
Du kopierst diese Datei nach reupper.config.yml und passt nur deine Werte an.

Wichtig:
Ändere die Kommentare in der .dist‑Datei ruhig, aber bearbeite immer deine Kopie reupper.config.yml, nicht das Original.

Im Folgenden gehen wir die wichtigsten Abschnitte und Optionen durch.

1. Lizenz

license: '' # REQUIRED | your license -> buy your license here: http://go-toolz.com
  • Was ist das?
    Dein persönlicher Lizenzschlüssel, damit go-reupper läuft.
  • Was eintragen?
    Den Schlüssel, den du von go-toolz bekommen hast.

Beispiel:

license: 'ABCDEF-123456-REUPPER'

Wenn der Schlüssel fehlt oder falsch ist, startet das Tool nicht korrekt bzw. bricht ab.

2. Arbeitsmodus (workmode) und Smart-Gruppierung (smart)

workmode steuert nur den Prepare-Pfad (wie Dateien vor dem Upload vorbereitet werden).
smart steuert optional die Gruppierung gleicher Titel und ist unabhängig vom Workmode.

workmode: 'normal' # REQUIRED | 'normal', 'lite' or 'lite-gdrive'
smart: false       # OPTIONAL | true = Mirror-Ordner mit gleichem Titel zusammenfassen

Prepare-Workmodes

  • normal
    • Standardmodus: laden, neu packen (RAR), hochladen, Links ersetzen.
  • lite
    • Vorhandene RAR‑Archive, MD5 anpassen, kein Neu‑Packen.
  • lite-gdrive
    • Laden von externen Quellen, danach wie lite.

Smart-Gruppierung

smart: true

Wenn smart: true:

  • Offline-Mirror-Ordner mit gleichem vorbereiteten Titel werden zu einem Job.
  • 1× Prepare (je nach workmode: packen oder lite/MD5 oder lite-gdrive).
  • Upload pro kanonischem Zielhoster, Link-Replace pro Originalordner.
  • Gilt für normal, lite und lite-gdrive.
  • Streamhoster bleiben Einzeljobs.

Empfehlung: Prepare mit normal starten; bei vielen Mirror-Ordnern smart: true setzen. Details: Smart-Gruppierung (Mirror-Ordner).

3. Allgemeine Einstellungen (general)

Ausschnitt aus reupper.config.dist.yml:

general:
  extractRARs: false
  slowmode: 5
  checkinterval: 600
  retryfaileduploads: 5
  keepLastElements: 0
  overwriteByDownload: false
  checkFreeSpace: false
  cleanWorkDir: true
  sort: 'name'
  searchRecursive: false
  checkpartial:
    enabled: false
    ignoreHoster:
      enabled: false
      hoster:
        - 'ddl.to'
  ignore:
    enabled: false
    keywords:
      - ''
  contains:
    enabled: false
    keywords:
      - 'reupload-me'
  replace:
    enabled: false
  cut:
    enabled: false
  parallel:
    hoster: 1
    copy: 1

Die wichtigsten Felder:

  • extractRARs

    • Gilt nur im normal-Modus. Bei true werden vorhandene RAR-Archive nach dem Kopieren entpackt und anschließend wie gewohnt als RAR neu gepackt.
    • Der Entpacker wird mit archive.extractor gewählt. Der Standard false bewahrt das bisherige Reupper-Verhalten.

  • slowmode

    • Wartezeit (Sekunden) nach einem fertigen Job.
    • Gut, um das System zu entlasten oder zwischendurch eingreifen zu können.

  • checkinterval

    • Intervall in Sekunden, in dem go-reupper neue Jobs/Ordner und Status prüft.
    • Empfehlung: 600 (10 Minuten) ist meist ein guter Start.

  • retryfaileduploads

    • Anzahl der Wiederholungsversuche bei fehlgeschlagenen Uploads.
    • Höher = robuster, aber dauert länger, bis ein definitiver Fehler steht.

  • keepLastElements

    • Hält die letzten X fertig bearbeiteten Ordner im Workdir, um Traffic zu sparen.
    • 0 = alles wird nach erfolgreichem Abschluss gelöscht (Standard).

  • overwriteByDownload

    • Wenn true, werden vorhandene Ordner im Workdir überschrieben.
    • Standard false, um unnötigen Traffic zu sparen.

  • cleanWorkDir

    • Wenn true, wird das Arbeitsverzeichnis nach erfolgreichem Job aufgeräumt.

  • searchRecursive

    • Wenn true, werden Scan‑Pfad‑Ordner rekursiv durchsucht.
    • Vorsicht, kann bei riesigen Strukturen viel Zeit kosten.

  • ignore / contains

    • ignore: Ordner mit bestimmten Stichwörtern im Namen werden übersprungen.
    • contains: Nur Ordner, die bestimmte Stichwörter enthalten, werden bearbeitet.

  • parallel (hoster/copy)

    • hoster: wie viele File- und Streamhoster eines Jobs gleichzeitig hochladen. 1 bleibt sequentiell. Es werden nur Hoster hochgeladen, die sowohl aktiv als auch am Job hängen – das gilt für normale Jobs und für Smart-Jobs mit mehreren Zielhostern.
    • copy: wie viele Dateien parallel kopiert werden.
    • Höhere Werte = schneller, aber mehr Last und mögliche Hosterlimits. Unabhängig davon steuert filehoster.services.*.parallel die parallelen Dateien pro Hoster.

Praxis-Tipp:
Am Anfang die Standardwerte lassen und nur checkinterval, slowmode und ggf. keepLastElements anpassen.

4. Bandbreite (bandwidth)

bandwidth:
  quota:
    enabled: false
    resetInterval: 'month'
    resetDay: 1
    download: 1099511627776
    upload: 0
  • Zweck:
    Schutz vor zu hohem Traffic (z. B. bei Volumentarifen).

Wichtige Felder:

  • enabled
    • true = Quota aktiv, false = keine Begrenzung.
  • resetInterval
    • 'month' oder 'day'.
    • Bei month wird z. B. monatlich zurückgesetzt.
  • resetDay
    • Bei month: Tag im Monat (1–31), an dem der Zähler auf 0 gesetzt wird.
    • Bei day: Stunde des Tages (0–23), zu der zurückgesetzt wird.
  • download
    • Maximal erlaubtes Download‑Volumen in Bytes (z. B. 1 TB).
  • upload
    • Maximal erlaubtes Upload-Volumen in Bytes. 0 zählt den geschätzten Upload-Traffic, blockiert Uploads aber nicht.

Empfehlung:
Wenn du dir unsicher bist, lass enabled: false.
Später kannst du bei Bedarf Limits setzen.

5. Ergebnis‑Einstellungen (result)

result:
  txt:
    enabled: false
    mode: 'default'
    path: ''

go-reupper kann fertige Jobs in Textdateien protokollieren:

  • enabled
    • true = Textdatei wird gepflegt, false = aus.
  • mode
    • 'default' = mehrere Zeilen pro Eintrag (Name, Hoster, Links).
    • 'inline' = alles in einer Zeile, durch Trennzeichen getrennt.
  • path
    • Vollständiger Pfad zur TXT‑Datei (z. B. C:\Results\reup-list.txt).

Wenn du das nicht brauchst, kannst du diesen Block deaktiviert lassen.

6. Pfade (path)

Auszug:

path:
  scan:
    - '/var/www/backup/'
    - 'C:\Users\You\Videos\'
  winrar: ''
  sevenzip: ''
  base: ''
  work: ''

Die wichtigsten Felder:

  • scan

    • Liste aller Ordner, die go-reupper überwachen und verarbeiten soll.
    • Wichtig: Pfade mit / oder \ abschließen.

  • winrar

    • Windows: kompletter Pfad zu WinRAR.exe (z. B. C:\Program Files\WinRAR\WinRAR.exe).
    • Linux: meist einfach rar, wenn im PATH.
    • Wird unabhängig vom gewählten Entpacker weiterhin zum Erzeugen der Kunden-RARs benötigt.

  • sevenzip

    • Nur erforderlich, wenn archive.extractor: '7zip' gesetzt ist.
    • Windows: kompletter Pfad zu 7z.exe; Linux/macOS: je nach Installation 7zz oder 7z.

  • base

    • Basis‑Pfad zum Tool. Wenn leer, versucht go-reupper den Pfad automatisch zu ermitteln.

  • work

    • Arbeitsverzeichnis für temporäre Dateien.
    • Wenn leer, wird standardmäßig files/ im Tool‑Verzeichnis genutzt.
    • Ein abschließender / oder \ ist optional; go-reupper verbindet die Pfadbestandteile selbst.

Praxisbeispiel (Windows):

path:
  scan:
    - 'D:\Reup\incoming\'
  winrar: 'C:\Program Files\WinRAR\WinRAR.exe'
  sevenzip: 'C:\Program Files\7-Zip\7z.exe'
  work: 'D:\Reup\work\'

Remote-Quellen (remote)

Zusätzlich zu lokalen path.scan-Ordnern ist ein neuer, standardmäßig deaktivierter remote-Block vorgesehen. Wenn Upper und Reupper dieselben FTP/FTPS/SFTP-Quellen nutzen sollen, kann der Block optional in eine gemeinsame Datei ausgelagert werden:

remoteConfig: '' # optional, z.B. 'remote.sources.yml'
remote:
  enabled: false
  statePath: 'database/remote-sources.db'
  firstScanMode: 'baseline-only'
  scanIntervalSeconds: 600
  servers: []
  • remoteConfig ist leer = der inline remote:-Block aus dieser Config wird benutzt.
  • remoteConfig: 'remote.sources.yml' = der externe remote:-Block aus config/remote.sources.yml wird geladen und ersetzt den inline Block.
  • Der Pfad wird relativ zur jeweiligen Haupt-Config aufgelöst; upper.config.yml und reupper.config.yml können also dieselbe Datei referenzieren.
  • Eine Vorlage liegt in config/remote.sources.dist.yml.
  • Unterstützt werden FTP, FTPS (explicit mit AUTH TLS oder implicit mit Port-990-Default) und SFTP.
  • Pro Section filtern filters.include und filters.exclude Release-Ordner vor dem FTP/SFTP-Download. Include-Zeilen sind ODER, Werte in einer Zeile bzw. [...] sind UND (Substring oder Glob wie *1080p*). Exclude gewinnt. Gematcht wird der Ordnername bzw. der Basename, nicht der Section-Pfad (movies trifft also nicht jeden Ordner unter /section/movies/). Muster mit / gelten zusätzlich für den Remote-Pfad. Leere Listen laden weiter alles. Einzelne Strings bleiben gültig. Beispiel: include: [2025, [GERMAN, 1080p]] und exclude: [2024].
  • Der erste Scan eines Servers oder einer Section legt nur eine Baseline an; es wird noch nichts automatisch heruntergeladen.
  • Automatisch erkannte Sections werden sichtbar gespeichert, bleiben aber deaktiviert, bis du sie aktivierst.
  • Beide Worker verwenden dieselbe Cache-Struktur unter path.work/remote. Sie teilen die tatsächlichen Downloads nur, wenn path.work und remote.statePath auf dieselben Speicherorte zeigen.
  • Ein eigener cachePath existiert aktuell nicht; Remote-Releases landen weiter unter path.work/remote/....
  • Downloads laufen zuerst in .partial/<release-id> und werden erst nach erfolgreichem Abschluss in den finalen Cache verschoben.
  • Vorhandene Partial-Dateien werden beim nächsten Versuch fortgesetzt: FTP/FTPS nutzt REST, SFTP nutzt Seek.
  • transferSlots/maxConnections begrenzen parallele Remote-Downloads pro Server.
  • SFTP nutzt known_hosts oder bewusst gesetztes insecure Host-Key-Handling und unterstützt Passwort- sowie Private-Key-Auth.
  • Remote-Downloads werden in die bestehende Bandwidth-Quota eingerechnet.
  • Upper-UI und Reupper-UI bieten unter Einstellungen > Remote Sources denselben Manager mit Instanzauswahl, Verbindungsdialog, Verbindungstest und Remote-Browser.
  • Die Reupper-UI verwendet dafür /api/reupper/remote/* und schreibt ausschließlich in die ausgewählte go-reupper-Instanz. Die Upper-UI verwendet entsprechend /api/upper/remote/*.
  • Section-Checkboxen und im Browser ausgewählte Ordner werden in die aktive Haupt-Config oder, falls gesetzt, in die externe remoteConfig-Datei geschrieben; automatisch erkannte Sections bleiben bis zur Aktivierung sichtbar, aber deaktiviert.
  • Das Browser-Popup kann den aktuell geöffneten Remote-Ordner über denselben Endpunkt als neue deaktivierte Section speichern.

7. Archive (archive)

archive:
  mode: 'rar'
  extractor: 'winrar'
  partsize: '200m'
  pw: ''
  md5change:
    enabled: false
    md5mode: 1
    iterations: 1
  randomname: true
  addfolder: false
  separatefiles: false
  winrar:
    options:
      extractRecursive: true
      extractOriginal: false
      silent: true
      exclude:
        - '*.json'
      customExtract: ''
      customCreate: ''
  sevenzip:
    options:
      extractRecursive: true
      extractOriginal: false
      silent: true
      customExtract: ''
  • mode: Aktuell ist rar der produktive Archivmodus; ZIP ist nicht implementiert.
  • extractor: Wählt ausschließlich den Entpacker (winrar oder 7zip). Ein leerer Wert bleibt aus Kompatibilitätsgründen bei WinRAR.
  • partsize: Größe der Archivteile, zum Beispiel 200m.
  • pw: Optionales Archivpasswort.
  • md5change: Steuert zusätzliche MD5-Änderungen. Bei RAR-Dateien verwendet Reupper bereits den speziellen RAR-Modus; die allgemeinen MD5-Optionen werden dann ignoriert.
  • randomname: Erzeugt zufällige Archivnamen.
  • addfolder: Packt den Quellordner statt nur seines Inhalts ein.
  • separatefiles: Erstellt für jede Datei ein eigenes Archiv und deaktiviert damit praktisch addfolder.

archive.sevenzip.options gilt ausschließlich beim Entpacken. extractOriginal wechselt zwischen 7z e (flache Ausgabe) und 7z x (Originalstruktur), extractRecursive verarbeitet auch Unterordner. Packen, Splitting, Ausschlüsse, MD5-Änderungen und customCreate laufen immer über archive.winrar.options und path.winrar; es werden keine 7z-Dateien erzeugt. Ändere benutzerdefinierte Argumente nur, wenn du den resultierenden Befehl getestet hast.

8. Hoster ersetzen (replacehoster)

replacehoster:
  enabled: false
  hosters:
    - hoster: 'uploaded.net'
      uploadto: 'ddl.to'

Dieser optionale Block ersetzt einen ausgefallenen Quellhoster durch einen anderen Zielhoster. hoster bezeichnet den bisherigen Dienst, uploadto den neuen Dienst. Der Zielhoster muss zusätzlich unter filehoster aktiviert und konfiguriert sein.

9. Linkcrypter (linkcrypter)

linkcrypter:
  service: 'filecrypt'
  apikey: ''
  multiHosterMode: false
  backup:
    enabled: false
    services:
      - service: 'hidecx'
        apikey: ''

Hier stellst du ein, welcher Linkcrypter verwendet wird:

  • service
    • filecrypt, tolink oder hidecx.
  • apikey
    • API‑Key des jeweiligen Dienstes.
  • multiHosterMode
    • Wenn true, werden mehrere Hoster in einem Ordner kombiniert.
  • backup
    • Optionaler zweiter Linkcrypter (z. B. Hide.cx, Keeplinks) zur Absicherung.

Ohne gültigen API‑Key kann der Linkcrypter keine Ordner erzeugen.

10. Filehoster und Streamhoster

In filehoster und streamhoster legst du fest:

  • welche Hoster aktiv sind (active‑Liste) und
  • welche Zugangsdaten sie verwenden (services‑Abschnitt).

Beispiel (stark gekürzt):

filehoster:
  options:
    fileSizeValidation: false
  active:
    - 'ddl.to'
    - 'ddownload.com'
  services:
    ddownload:
      apikey: ''
      proxy: false
      parallel:
        active: false
        number: 2
        retryfailed: 7

Wichtige Punkte:

  • In active steht, welche Hoster überhaupt verwendet werden.
  • Unter services trägst du die Logins/API‑Keys für jeden Dienst ein.
  • parallel.active und number regeln parallele Dateien zu einem Hoster – vorsichtig benutzen.
  • Mehrere Hoster gleichzeitig steuerst du mit general.parallel.hoster.
  • Für uploadg.com trägst du bei apikey den Bearer-Token aus https://uploadg.com/account-settings ein.
  • uploadg.com nutzt automatisch den Multipart-S3-Upload und ist damit auch für große Dateien gedacht; der alte /uploads-Endpunkt wird nicht mehr verwendet.

Bei streamhoster funktioniert es analog, nur für Video‑Hoster.

11. Z-O-O-M Uploader (zoom)

zoom:
  enabled: false
  webcontrol:
    host: 'localhost'
    port: '8080'
    user: 'test'
    password: 'test'

Wenn du den Z-O-O-M FileUploader mit WebControl nutzt, kannst du go-reupper über diese Schnittstelle hochladen lassen.

  • enabled
    • true = ZOOM-Modus aktiv, false = normale Upload‑Logik.
  • Weitere Werte müssen zu deiner ZOOM‑Installation passen.

Wenn du ZOOM nicht einsetzt, lässt du enabled: false.

12. Proxies (proxies)

proxies:
  - 'socks5://user:pass@host:1080'

Hier kannst du SOCKS5‑Proxies eintragen, die für Uploads verwendet werden.
Mehrere Einträge sind möglich; sie werden zufällig verwendet.

Wenn du keine Proxies nutzt, lässt du die Liste entweder leer oder die Beispielzeile auskommentiert.

13. Curl-Unterstützung (curl)

curl:
  enabled: true
  filehosters:
    - 'ddownload.com'
    - 'katfile.cloud'
    - 'drop.download'
    ...
  • enabled
    • true = Uploads für bestimmte Hoster werden über curl abgewickelt (speicherschonender).
    • false = interne HTTP‑Client‑Logik.

In filehosters ist aufgelistet, welche Hoster Curl verwenden sollen.
Standardwerte sind in der Dist‑Datei schon sinnvoll gesetzt.

Bei Curl-Uploads zeigt go-reupper in einem interaktiven Terminal automatisch einen Fortschrittsbalken pro Datei an. Bei parallelen Uploads werden mehrere Balken untereinander dargestellt. Wird die Ausgabe in eine Datei oder einen Prozess umgeleitet, deaktiviert go-reupper die Animation automatisch und schreibt weiterhin normale Logmeldungen.

14. Benachrichtigungen (notification)

notification:
  enabled: false
  notifyOn:
    error: true
    success: false
    summary: false
  pushover:
    enabled: false
    userkey: ''
    apikey: ''

go-reupper kann dich z. B. via Pushover über Fehler oder erfolgreiche Reuploads informieren.

  • enabled + pushover.enabled müssen beide auf true stehen.
  • userkey und apikey bekommst du von Pushover.
  • notifyOn.summary: true schickt nach einem Durchlauf mit verarbeiteten Jobs eine Übersicht (ok / failed / Dauer). Leere Durchläufe erzeugen keine Nachricht.

Für einen einfachen Start kannst du das komplett deaktiviert lassen.

15. Arbeitszeiten (workingtime)

workingtime:
  enabled: false
  timezone: "Europe/Berlin"
  monday:    "09:00-17:30"
  tuesday:   "09:00-17:30"
  ...

Damit kannst du definieren, wann go-reupper arbeiten darf:

  • enabled: true → Zeitplan aktiv.
  • Pro Wochentag entweder ein Zeitfenster "HH:MM-HH:MM" oder "" (kein Betrieb).

Wenn du das nicht brauchst, bleibt enabled: false.

16. Experteneinstellungen (expert)

expert:
  updateFolderModificationTime: false

Diese Optionen sind für Spezialfälle gedacht.
Wenn du nicht genau weißt, was sie tun, lass die Standardwerte unverändert.

Zusammenfassung

Für einen sicheren Start mit go-reupper reicht es, wenn du in reupper.config.yml:

  1. license setzt,
  2. workmode auf einen sinnvollen Modus stellst (meist normal),
  3. unter path mindestens einen scan-Pfad sowie winrar und bei Bedarf work pflegst,
  4. im linkcrypter einen Dienst + API‑Key einträgst und
  5. bei filehoster mindestens einen Hoster aktivierst und konfigurierst.

Alle anderen Optionen kannst du nach und nach anpassen, sobald dein Grundsetup stabil läuft.

Für konkrete Betriebs-Setups siehe zusätzlich „Go-Reupper -> How-Tos“.

Previous Erste Schritte Next Weboberfläche