Set Up Infinitum RSS and AI Reports with Localtonet

How the Infinitum and Localtonet deployment fits together

The installation has two distinct layers. Infinitum is the application layer: it gathers RSS-based information, presents it through a web interface, and supports AI daily report functionality. Docker Compose runs the application on the self-hosted machine. In the documented Docker deployment, the host listens at http://localhost:3001 and maps that endpoint to port 3000 inside the container.

Localtonet is added only after the application works locally. Our client runs on the Infinitum host, or on another device that can reach it, and establishes an outbound connection to a Localtonet relay server. An HTTP tunnel then points to the local Infinitum address and port. The tunnel provides a public HTTPS address while it is running and while the selected Localtonet device remains connected.

This separation is important for diagnosis. If Infinitum does not answer locally, changing a tunnel will not repair the application. If Infinitum works locally but the public address does not, the investigation moves to the Localtonet client, tunnel state, selected device, relay connection, or local target. Always complete local verification before adding remote access.

Docker port mapping versus application port

Two ports appear in this deployment, and confusing them is a common source of errors. Port 3000 is the container-side application port. Port 3001 is the host-side port documented for the Docker deployment. A browser running on the Docker host therefore uses http://localhost:3001. The Localtonet HTTP tunnel should also target the reachable host-side endpoint, not an isolated container-only address.

The project separately documents an npm-based local development setup at http://localhost:3000. That is not the same workflow as the Docker Compose installation in this article. Do not switch between ports simply because one appears in development documentation. Confirm which installation method is running, then use its corresponding endpoint.

Prerequisites and deployment decisions

Prepare the host before editing the Compose configuration. You need a system with Docker Engine and the current Docker Compose plugin installed, permission to run Docker commands, enough storage for the application images and generated data, and a web browser for verification. You also need a copy of the Infinitum repository because the documented workflow starts from its example Compose file.

Docker installation steps differ by operating system and distribution. Verify the installation instead of assuming it succeeded:

docker --version
docker compose version

Both commands should return version information. If the second command is unavailable, install or enable the Docker Compose plugin appropriate to the host. This guide uses the modern docker compose form shown by the Infinitum instructions, not the older standalone docker-compose command.

Values to prepare

• An administrator password: Infinitum documents ADMIN_PASSWORD as a required configuration value. Choose a unique password that is not reused on another service.
• An administrator session secret: Infinitum documents ADMIN_SESSION_SECRET. Use a strong, unpredictable value and keep it out of screenshots, tickets, shell history, and published configuration examples.
• A site URL: Infinitum documents SITE_URL. For the first local test, the Docker endpoint is http://localhost:3001. If the deployed version uses this setting as its canonical external address, update it after Localtonet assigns the public URL.
• RSS feed URLs: Gather the actual feed endpoints rather than ordinary website home pages. An RSS or Atom URL should return a machine-readable feed document.
• AI configuration required by your build: Provider names, model identifiers, credentials, endpoints, and optional report controls are not established by the evidence available for this draft. Do not guess them. Follow the fields displayed by the installed release and the project documentation shipped with that release.

Choose the machine that will run the tunnel

The simplest design runs the Localtonet client on the same machine as Docker. In that case, an HTTP tunnel can target the host endpoint on port 3001. A different device can also run the client if it can reach the Infinitum host over the local network, but its target must use the Infinitum host's reachable LAN address instead of 127.0.0.1 or localhost.

Remember that localhost always refers to the machine making the connection. If our client runs on another computer, localhost:3001 points back to that other computer, not to the Infinitum server.

Install Infinitum with Docker Compose

Work from the root of the Infinitum repository, where docker-compose.yml.example is located. The documented installation path is to copy the example, configure the required values, pull the images, and start the application. Review the example before running it so that you understand its volume, image, network, and port declarations.

cp docker-compose.yml.example docker-compose.yml

docker compose pull

docker compose up -d

Inspect the resulting container state

Docker Compose provides standard commands for checking the project after startup:

docker compose ps
docker compose logs

The first command shows the service state and published ports. The second displays available logs from the Compose project. If the logs are lengthy, focus on the earliest startup error and any repeated failure. Common categories include malformed configuration, unavailable image downloads, a port conflict, inaccessible storage, or an invalid required value.

Configure RSS sources and AI daily reports

Complete this work only after the web interface loads. Feed ingestion and AI report generation add dependencies beyond basic page startup, so test them in layers. Begin with one known feed, confirm that Infinitum can retrieve and display its entries, and only then add more sources or enable AI processing.

Add and validate RSS feeds

The project includes dedicated RSS usage documentation, but the supplied evidence does not expose the current screen labels, accepted request fields, refresh controls, or scheduling defaults. Those details may change between releases. In the deployed interface, locate the feed or source management area and use the current controls to add an RSS or Atom endpoint.

A reliable feed setup workflow is:

1. Open the intended publisher's actual RSS or Atom endpoint in a browser or feed-aware tool.
2. Confirm that the URL returns a feed document rather than a marketing page, sign-in screen, bot challenge, or generic HTML error.
3. Add one source using the fields exposed by the installed Infinitum build.
4. Trigger or wait for the retrieval behavior documented by that build.
5. Verify that entry titles, source identity, publication times, and article links appear as expected.
6. Add further sources gradually so that a failing feed can be identified without searching through a large batch.

A normal web page and an RSS feed are not interchangeable. A feed is a structured document designed for syndication. If a publisher has moved or removed its feed, Infinitum cannot correct the remote endpoint. Find the publisher's current feed URL or remove the stale source.

Prepare AI daily report generation

Infinitum includes daily-report administration routes and project documentation for report templates and AI refinement. However, the supplied evidence does not establish the exact AI providers, environment variable names, model defaults, credential fields, scheduling behavior, prompt schema, or buttons in the current release. We therefore cannot safely provide a copied configuration block or claim that a particular provider works without additional verified documentation.

Use the following release-aware process instead:

1. Open the daily report settings provided by the installed build.
2. Read the accompanying template usage documentation from the same project revision.
3. Supply only the provider, model, endpoint, credential, template, and generation values explicitly requested by that version.
4. Keep provider credentials private and apply the minimum permissions available from that provider.
5. Generate a test report from a small set of successfully ingested RSS entries.
6. Inspect the report for missing source material, unsupported claims, broken formatting, and unexpected language or time ranges.
7. Only after manual generation works should you rely on any scheduling feature documented by your release.

Use a controlled first report

A small test set makes problems easier to classify. If the source entries are already incorrect, repair RSS ingestion first. If the entries are correct but report generation fails, inspect the AI configuration and application logs. If generation completes but the report quality is poor, review the selected input range and the supported report template controls. This layered approach avoids treating every issue as an AI provider failure.

Do not call an undocumented administrative API endpoint directly merely because its source directory exists. A directory path in the codebase does not establish the supported HTTP method, authentication requirements, request schema, response schema, or compatibility guarantees. Use the documented interface unless the project publishes an API contract for the exact installed version.

Verify Infinitum locally before remote exposure

Open the documented Docker endpoint on the machine running Docker:

http://localhost:3001

A complete verification should test more than the initial page. Authenticate with the configured administrator password, confirm that the interface remains usable after navigation, add or inspect an RSS source, and generate a small daily report if the AI settings have been completed. Refresh the page or open a new browser session to confirm that the service is not depending on a stale frontend state.

Test from the Docker host

• Confirm that http://localhost:3001 opens without a connection error.
• Verify that the expected Infinitum interface appears, not another service using the same port.
• Sign in with the configured administrator credentials.
• Confirm that at least one valid feed can be retrieved and displayed.
• Test report generation only after the selected source entries exist.
• Review docker compose logs for repeated errors even if the page appears to load.

Test from another LAN device when needed

If the Localtonet client will run on another machine, test Infinitum from that machine before creating the tunnel. Replace localhost with the Docker host's LAN address and keep port 3001. The exact LAN address depends on the network and must not be guessed.

A failure from another device while local access works usually points to host binding, host firewall policy, network segmentation, or an incorrect LAN address. Do not weaken firewall rules broadly. Permit only the necessary trusted path, or run the Localtonet client directly on the Infinitum host so it can use the local endpoint.

Expose the working Infinitum service with Localtonet

Once Infinitum works locally, use an HTTP tunnel for browser access. Our client makes an outbound connection to a selected Localtonet relay, so this workflow does not require inbound router port forwarding, a public IP address, firewall changes, or a VPN. The public address is available only while the selected device is connected and the tunnel is running.

Install and run the Localtonet client on the Docker host when possible. If it runs elsewhere, that device must be able to reach the Infinitum host at the LAN address and port already tested. Device authentication tokens are device-specific. Never paste a real token into public documentation, source control, screenshots, or support messages.

For the current dashboard workflow and fields, consult our HTTP tunnel documentation. Exact custom-domain DNS instructions are intentionally not included because they must be checked against the current Localtonet documentation before use.

Update SITE_URL carefully

After the tunnel assigns a public URL, review how the installed Infinitum version uses SITE_URL. If its documentation requires the external canonical URL there, replace the local value with the exact assigned HTTPS address and apply the Compose configuration again:

docker compose up -d

This qualification matters because the available evidence confirms the setting's name but does not establish every place it affects URL generation, session behavior, redirects, or report links. If changing it causes a redirect loop or login problem, restore the last working value, review the application logs, and check the version-matched Infinitum documentation.

Routine operation, updates, and backups

Self-hosting continues after installation. Keep a record of the Infinitum version, Compose configuration, chosen image policy, local endpoint, Localtonet target, and any external AI dependency. This makes future upgrades and incident response more predictable.

Update in a controlled sequence

1. Record the currently deployed version and confirm that the existing service works.
2. Back up persistent application data and the working configuration using a method appropriate to the storage declared by the current Compose file.
3. Read the target release notes for configuration, migration, image, and data changes.
4. Pull the intended images with docker compose pull.
5. Apply the deployment with docker compose up -d.
6. Inspect status and logs.
7. Repeat local RSS and report tests before testing the public URL.

The supplied evidence does not identify Infinitum's exact persistent volume names or backup and restore commands. Inspect the version-matched Compose file before designing a backup procedure. Do not assume that copying the Compose file alone preserves feeds, reports, settings, or other application state.

Stop unused access paths

If remote access is temporary, stop the Localtonet tunnel after the task is complete. The public address will not remain available through that tunnel while it is stopped. If the tunnel will never be used again, delete it. If the Localtonet client device disconnects, the tunnel also becomes unavailable even if its dashboard configuration still exists.

Troubleshooting Infinitum and the HTTP tunnel

The Compose command cannot find a configuration file

Confirm that the terminal is in the repository directory containing docker-compose.yml. If only docker-compose.yml.example exists, complete the documented copy step. Also verify that the copied filename has not acquired an extra extension.

Port 3001 is already in use

Another process may already be bound to the host port. Identify that process using tools appropriate to the operating system. The safest resolution is normally to stop the unintended service or deliberately revise the Compose port mapping. If you change the host port, use that new host port consistently for local verification and the Localtonet target. Do not change the container port merely to resolve a host-side conflict unless the application documentation explicitly supports it.

The containers start and then stop

Run docker compose ps and docker compose logs. Check the earliest relevant error rather than only the final shutdown message. Revisit the three documented configuration values and verify the Compose syntax. If an image cannot be downloaded, check the host's DNS resolution, outbound connectivity, registry access, and available storage.

The browser cannot open localhost:3001

Verify that the Docker installation, Compose project, and port mapping belong to the same host where the browser is running. Confirm that the deployment is the Docker workflow rather than the npm development workflow. Then inspect the published ports in docker compose ps and review the logs.

RSS entries do not appear

Open the feed URL independently. If it returns HTML, redirects to authentication, presents a bot challenge, or produces an error, the source itself may not be retrievable as a feed. If it returns structured RSS or Atom content, check Infinitum's logs and the current version's feed controls. Also confirm that date filters or grouping selections are not hiding successfully retrieved entries.

AI report generation fails

First confirm that Infinitum has source entries available for the intended report period. Then verify the exact provider settings requested by the installed release, without posting the credential in logs or support messages. Check for provider-side authorization, model access, endpoint, rate, quota, or payload errors. Because the available evidence does not establish supported providers or variable names, use only the configuration contract documented by that Infinitum version.

Infinitum works locally but not through Localtonet

• Confirm that the selected Localtonet device is connected.
• Confirm that the HTTP tunnel has been started, not merely created.
• Test the exact local target from the device running our client.
• If the client is remote from Docker, replace localhost with the tested LAN address.
• Confirm that the target uses the Docker host port 3001.
• Check whether Infinitum redirects to a stale SITE_URL.

The public URL opens but login or redirects fail

Compare the current SITE_URL with the address used in the browser and consult the deployed version's documentation for canonical URL handling. Clear only the relevant test session or use a private browser window after correcting configuration. Do not disable authentication to work around a login or redirect problem.

Security checklist for remote Infinitum access

Treat the deployment as an internet-reachable application once the HTTP tunnel starts. Router isolation alone no longer limits who can reach the login page. The goal is not to weaken controls for convenience, but to expose only the intended service while retaining strong application authentication and disciplined secret management.

• Do not embed Localtonet device tokens or AI credentials in public examples.
• Do not expose Infinitum before changing placeholder administrator values.
• Do not disable application authentication merely because the public URL is difficult to discover.
• Do not publish administrative API routes without understanding their authentication and supported contract.
• Back up persistent data before upgrades or storage changes.
• Review application and container logs, but redact secrets before sharing diagnostic excerpts.
• Use least-privilege AI credentials where the selected provider supports them.
• Review generated reports before distributing or relying on them.

Frequently asked questions