Rimgo Hosting
Browse Imgur images and albums through a fast, private front-end with no tracking or ads.
- One click deploy
- 1 GB RAM Memory needed
- 15 GB Disk Space Needed
- From 2 € Price
Tech
- Docker image
- codeberg.org/rimgo/rimgo:latest
- Default port
- 3000
How Rimgo works
Rimgo accepts an Imgur image, gallery, or album path, requests the relevant upstream content through the server, and renders a simplified page for the visitor. The project is read-only and works without client-side JavaScript for its core browsing flow. Browser redirection extensions can replace supported Imgur links with the hosted Rimgo domain.
The instance remains dependent on Imgur returning compatible content. Changes to upstream routes, access rules, rate limits, media delivery, or page structure can break individual items or the whole frontend until the project adapts. Rimgo cannot restore content that Imgur removed or restricted.
Key Rimgo features
Images and albums can be viewed without the sign-up prompts and tracking scripts associated with the original website. A lightweight page reduces client work, while redirection tools make it practical to open familiar links through the alternative frontend. The service is most useful as a privacy-oriented reader rather than a full image community.
Rimgo does not provide uploads, accounts, comments, moderation, private albums, or a durable local media archive. Any caching or locally retained operational data follows the instance configuration, while the source media remains controlled by Imgur and its users.
Who uses Rimgo
Privacy-focused users can open public Imgur links, forums can suggest a cleaner reader, and administrators can provide an internal redirect target for approved browsing. It is particularly useful when a group only needs to view existing images and galleries.
Rimgo is not appropriate for publishing new images, managing an account, interacting socially, or guaranteeing long-term availability. A critical image should be preserved separately when the user has the right to keep a copy. Public links can change or disappear, so the frontend should not become the sole archive for material needed in research, evidence, or documentation.
Self-hosting Rimgo: requirements and cost
Resource use depends on visitors, upstream image size, albums, proxy traffic, cache behaviour, and concurrent requests. Rimgo’s catalogue stack has no PostgreSQL or MariaDB dependency. The mapping treats it as storage-driven, so 50 GB on Plan 3 is a realistic starting point when cache or retained assets grow, while 100 GB on Plan 4 better suits a larger public-facing workload.
AvaHost maps Rimgo to Plan 1 at €2. One-click provisioning, a custom HTTPS hostname, automatic application updates, and scheduled backups are included. The plan does not provide an Imgur account, upload service, content licence, or assurance that upstream routes will remain available. Users must respect the rights and privacy attached to the images they access.
F.A.Q
Rimgo starts at €2 on Plan 1. Visitors, image size, album length, proxy traffic, cache behaviour, and concurrent requests shape demand. The mapping treats it as storage-driven: Plan 3 offers 50 GB for growing cache or retained assets, while Plan 4 offers 100 GB for a larger public-facing reader.
A custom hostname can serve Rimgo with automated HTTPS after DNS points to AvaHost. Users may configure supported redirection tools to rewrite Imgur links to that address. Test image, album, gallery, and mobile links after any domain change, and update extension rules or community documentation that still references the earlier instance URL.
Rimgo is a read-only alternative frontend. It does not reproduce Imgur accounts, uploads, comments, moderation, private libraries, or other social features. The hosting plan also does not include an Imgur account. Use a separate lawful publishing service when content must be uploaded, managed, or retained under the user’s own control.
Rimgo depends on Imgur content and compatible upstream behaviour. Removed media, access restrictions, rate limits, route changes, or delivery changes can cause failures until the frontend adapts, and some items may not return. Preserve important content separately only when authorised, because the alternative frontend does not create ownership or long-term availability.