# wabarc/wayback: a self-hosted CLI and bot for pushing pages into Internet Archive, archive.today and IPFS > wayback is a Go archiving tool with a command line and IM bot interfaces that submits URLs to several archive services at once. It is for people who want archive submission inside their own workflow, not for browsing the Wayback Machine. **wabarc/wayback** — An archiving tool with an IM-style interface that prioritizes privacy and accessibility, integrated with various archival services including Internet Archive, archive.today, Ghostarchive, IPFS, Telegraph, and file systems. - Repository: https://github.com/wabarc/wayback - Website: https://docs.wabarc.eu.org - Stars: 2,234 · Forks: 88 - Language: Go - License: GPL-3.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/wabarc-wayback ## What wabarc/wayback actually does, and who it is for The name causes most of the confusion. The Internet Archive's Wayback Machine is a public playback site for old pages. wabarc/wayback is the opposite end of that pipeline: a tool that submits a URL to archiving services and returns the resulting snapshot links. The README describes it as "a web archiving and playback tool" for "web archivists, researchers, and anyone who wants to preserve web content". The practical audience is narrower than that sentence suggests. If you paste links into web.archive.org by hand, or if you keep a notes file of archive URLs for citations, wayback turns that into one command or one chat message. It also suits people running a community archive who want submissions to land in several places at once, because a single snapshot service can go down or drop content. The repository topics list IRC, Matrix, Telegram, Mastodon, Nostr, Notion and self-hosted, which is a fair summary of where it is meant to live. It is not a crawler and not a search engine. There is no scheduling of recurring captures described in the README, and no crawl-scope configuration. You hand it URLs; it pushes them out. ## How the archiving pipeline is put together wayback is written in Go and ships as a single binary, with the command dispatch handled by cobra (the flag list in the README is a cobra help screen). The archiving targets are separate Go modules maintained under the same wabarc organisation: github.com/wabarc/archive.org, github.com/wabarc/archive.is, github.com/wabarc/ghostarchive and github.com/wabarc/ipfs-pinner all appear in go.mod. That layout means adding a service is a matter of adding a module, and it also means the per-service quirks live outside the main repository. Each target has a flag, and the defaults are on. The README's help output shows --ia (Internet Archive), --is (archive.today), --ip (IPFS), --ga (Ghostarchive) and --ph (Telegraph) each marked "default true". Running wayback with no flags on a bare URL therefore fans out to several services, which is convenient and also the first thing to think about if you care where your URLs end up. The daemon side is a second layer on the same binary. The -d flag takes a comma-separated list: telegram, web, mastodon, twitter, discord, slack, irc, xmpp. In daemon mode the process listens on those channels and treats incoming messages as archive requests. The docker-compose.yml in the repository shows the intended self-hosted shape: a wayback container running wayback -d web on port 8964, a chromedp/headless-shell browser container on 9222 for rendering, and a Meilisearch container on 7700 holding the index, with the wayback container pointed at both through CHROME_REMOTE_ADDR and WAYBACK_MEILI_ENDPOINT. ## Installing wayback and archiving a first URL The README's shortest path is the install script, which fetches a release binary. Run it and you should end up with a wayback executable to place on your PATH. ```bash curl -fsSL https://get.wabarc.eu.org | sh ``` If you prefer a package manager, the README also documents Homebrew, Snapcraft, APT and RPM. The Homebrew route is two commands and is the least invasive on macOS: ```bash brew tap wabarc/wayback brew install wayback ``` Go users can build from source instead. The module path is the one in go.mod, so the install target is the cmd directory: ```bash go install github.com/wabarc/wayback/cmd/wayback@latest ``` Now archive something. With no flags, the default-enabled services are used, and the command prints the resulting snapshot URLs: ```bash wayback https://www.wikipedia.org ``` To restrict a run to one service, pass its flag. The README gives these three as separate examples: ```bash wayback --ia https://www.fsf.org wayback --is https://www.fsf.org wayback --ip https://www.fsf.org ``` The IPFS target can go through a pinning service rather than a local daemon. The README sets three environment variables for Pinata: ```bash export WAYBACK_SLOT=pinata export WAYBACK_APIKEY=YOUR-PINATA-APIKEY export WAYBACK_SECRET=YOUR-PINATA-SECRET wayback --ip https://www.fsf.org ``` Before any of that, run wayback -h to see the full flag list on your build, and wayback --print to dump the effective configuration. The README lists the config file search order as ./wayback.conf, ~/wayback.conf, /etc/wayback.conf, overridable with -c. ## Where wayback stops being the right tool The most common mismatch is expecting playback. wayback submits pages and returns links; the README's playback wording refers to the daemon's web mode backed by Meilisearch, not to browsing the Internet Archive's historical corpus. If your goal is to see what a site looked like in 2014, this is not the program you want. Some targets are outside your control in ways that matter. archive.today is known for aggressive bot filtering, and the README gives no retry policy, no backoff configuration and no documented failure handling for a rejected submission. The same silence applies to the Internet Archive: the README does not document what happens when a capture is queued but never completes, or how to check on a submission later. There is no rollback described either. If a submission succeeds, the README does not document a way to withdraw it. IPFS is the target with the most setup cost. The default mode is --ipfs-mode pinner, and the README notes the IPFS daemon host defaults to 127.0.0.1 on port 5001, so a local daemon is assumed unless you configure a pinning service. Streaming media download additionally requires FFmpeg, which the README states as a dependency rather than bundling. Finally, the project is GPL-3.0. If you are embedding wayback into a proprietary product, that licence is a design constraint, not a detail. The repository also carries a cosign.pub and a .licenserc.yaml, so signature and licence-header checks are part of the project's own build hygiene. ## wayback compared with archivebox and with the Wayback Machine itself The closest self-hosted alternative in spirit is ArchiveBox, which takes the opposite architectural bet. ArchiveBox saves the content itself: it stores HTML, screenshots, PDFs, media and WARC files on your disk and gives you a local index over them. wayback mostly hands URLs to third-party services and stores what those services return. The README does mention file-system storage as a feature, and the compose file mounts a storage volume at /data, but the primary model is submission, not local preservation. If the services you submit to disappear, your links point at nothing; if your ArchiveBox disk dies, the same is true. The difference is who holds the copy. Against the Internet Archive's own Save Page Now, the difference is interface and fan-out. Save Page Now archives to one place and is operated by someone else. wayback archives to several places from a shell, a bot or a cron job you control, and can route traffic through Tor (--tor) or run as a hidden service. That is a real distinction for anyone archiving material they would rather not tie to their own IP address. The honest summary: wayback is a submission multiplexer, not a preservation system. It is strongest when paired with a local store you also control. ## Maintenance cost, releases and the GPL-3.0 licence The last push to the repository was on 2026-09-07, and the most recent release listed is v0.21.1 from 2026-07-05. Before that the release history jumps from v0.21.1 back to v0.20.1 and v0.20.0, both dated 2024-07-02. That gap is worth reading carefully: the project is not dormant, but it does not ship on a tight cadence, and a year-long stretch between v0.20.x and v0.21.x is visible in the release list. Operationally, the upgrade surface is small if you use the CLI: a single binary from GitHub Releases, Homebrew, Snapcraft, APT or RPM, plus the optional config file. The daemon deployment is heavier. The compose file pins getmeili/meilisearch:v1.1.0 and chromedp/headless-shell, and the Dockerfile builds on golang:1.26-alpine with an alpine:3.17 runtime. Those are three moving parts to keep current, and the Meilisearch pin in particular will drift from upstream releases. On licensing, wayback is GPL-3.0, and the Dockerfile labels the image org.opencontainers.image.licenses=GPLv3. Running the binary as a service and modifying the source are different situations under that licence, and the repository's LICENSE file is the authoritative text. This is a description of what the repository states, not legal advice; if you plan to redistribute a modified wayback, have someone qualified read the licence. ## Conclusion Adopt wayback if you already archive links by hand and want that submission step to run from a shell, a chat bot or a cron job across several services at once. Do not adopt it if what you actually want is to read old snapshots: that is the Wayback Machine's playback site, and wayback only submits and indexes. Before committing, run wayback --print against your own wayback.conf and confirm which of the default-enabled targets (--ia, --is, --ip, --ga, --ph) you are willing to send URLs to, because they are on unless you turn them off. ## FAQ ### Is wabarc/wayback the same thing as the Internet Archive's Wayback Machine? No. The Internet Archive's Wayback Machine is the public playback site, while wabarc/wayback is a tool that submits URLs to archiving services including Internet Archive and returns the snapshot links. The README describes it as an archiving and playback tool with an IM-style interface, but its own playback is the daemon's web mode backed by Meilisearch. ### How do I install wabarc/wayback? The README's simplest route is the install script, curl -fsSL https://get.wabarc.eu.org | sh, which fetches a release binary to place on your PATH. It also documents Homebrew, Snapcraft, APT, RPM, Bina, and go install github.com/wabarc/wayback/cmd/wayback@latest from source. ### How do I use wabarc/wayback to archive a page? Run wayback followed by one or more URLs, for example wayback https://www.wikipedia.org, and it submits to the services that are enabled by default. To target a single service, pass its flag such as --ia for Internet Archive, --is for archive.today, or --ip for IPFS. ### How do I use wabarc/wayback to archive a page from Twitter or Instagram? The README does not document per-site handling for Twitter or Instagram. The tool takes a URL and submits it to the enabled archiving services, so any site-specific behaviour comes from those services rather than from wayback itself. ## Sources - [License: GPL-3.0](https://github.com/wabarc/wayback/blob/main/LICENSE) - [Project website](https://docs.wabarc.eu.org) - [README](https://github.com/wabarc/wayback/blob/main/README.md) - [Releases](https://github.com/wabarc/wayback/releases) - [wabarc/wayback on GitHub](https://github.com/wabarc/wayback) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/wabarc-wayback