Install Seal Report and Access It with Localtonet

How the Seal Report deployment fits together

Seal Report & Task is a reporting and task framework written in C# for Microsoft .NET. It can query relational databases, MongoDB, Excel, CSV, XML, HTTP JSON, and other supported data sources. Its reporting features include dynamic SQL, LINQ queries, pivot tables, HTML charts, KPI and widget views, drill-down navigation, scheduled execution, and output formats such as HTML, Excel, PDF, XML, JSON, text, and CSV.

Several components participate in a complete self-hosted installation. The Server Manager declares data sources and manages server configuration. The Report Designer creates reports. The Web Report Server publishes configured reports through a browser interface. Scheduler components can run reports and tasks automatically. A normal installation should therefore be treated as an application deployment rather than as a single executable that can be made public immediately.

The important networking boundary is between the Web Report Server and its data sources. Remote users should normally reach the web application, not a database listener. Seal Report performs database access from the server side using the data-source configuration and credentials available to the application. Localtonet then publishes only the selected local web endpoint.

This separation makes testing easier. First prove that Seal Report can connect to the intended source and run a report. Next prove that the Web Report Server works in a browser on the local network or host. Only then add remote access. If a remote request later fails, this sequence helps determine whether the issue belongs to Seal Report, IIS or the selected web host, the operating-system firewall, or the tunnel target.

Prerequisites and supported installation paths

Seal Report 10 targets .NET 10. The required runtime depends on which component and operating system you intend to run. The Report Designer and Windows scheduler require Microsoft Windows Desktop Runtime 10. The Web Report Server requires the ASP.NET Core Runtime 10, with the Hosting Bundle used when hosting it on IIS. Microsoft Edge WebView2 is required for the Report Designer.

You also need the correct driver for each data source. A reporting application cannot connect to a server merely because the server is reachable over the network. The operating system and Seal Report process must have a compatible OLE DB, ODBC, SQL Server, Oracle, MySQL, SQLite, PostgreSQL, MongoDB, or other required provider. Driver architecture, credentials, TLS requirements, and database permissions must match the source being configured.

Plan the host before installing

Decide whether the complete reporting workflow will run on one Windows machine or whether the Web Report Server will be deployed separately. The documented Windows setup installs the desktop administration and design tools, scheduler components, and a default repository. This is the most directly documented path for a new installation. A Linux Web Report Server is supported, but its deployment is a publication workflow rather than the same Windows setup-executable workflow.

Before proceeding, identify the database or other source, the driver it needs, the account Seal Report will use, and the reports that remote users should be able to see. Use a dedicated database identity with only the permissions needed for reporting. Read-only access is preferable when reports only retrieve data. If a report or task intentionally writes data, grant only the specific write permissions it requires.

Choose an appropriate release

Obtain Seal Report from the project's GitHub Releases rather than from an unofficial software mirror. Review the release notes before installing or upgrading. Seal Report 10.0.1 is identified as a security and maintenance update and includes Web Report Server hardening related to path traversal, HTTPS session-cookie behavior, RSA padding, anti-clickjacking headers, and HTML escaping. It also updates AngleSharp and .NET packages.

Version-specific runtime requirements matter. Seal Report 10 requires the version 10 runtime family described above. An older runtime already present on a server should not be assumed to satisfy that requirement. Likewise, future Seal Report releases may change runtime requirements, so verify the release notes if you install a version newer than the one covered here.

Install Seal Report on Windows

The supported Windows installation begins with the setup executable from the official release. The setup installs Report Designer, Server Manager, Seal Scheduler Service, Task Scheduler, and a default repository. The evidence available for this guide documents the setup executable path, but it does not provide unattended-install switches. Run the installer interactively rather than guessing command-line options.

The standard installation places the Web Report Server distribution files under C:\Program Files\Seal Report\Web and C:\Program Files\Seal Report\NETCore. These directories contain files used to publish the application. They should not be treated as the public URL, and browsing directly to a file-system path does not test the server. The application must first be published through IIS or another documented hosting workflow.

What about Linux installation?

Seal Report supports publishing the Web Report Server on Linux with the ASP.NET Core Runtime 10. However, the verified general installation material supplied for this guide does not define one universal Linux distribution, package-manager command, service unit, deployment directory, startup command, listening port, or reverse-proxy configuration. Those details depend on the dedicated Linux deployment procedure and the selected operating system.

We therefore do not provide speculative shell commands. For a Linux deployment, install the exact ASP.NET Core Runtime version required by your Seal Report release, follow the project's dedicated Linux publication instructions, and record the resulting process command and listening address. Continue with this guide at the local-verification stage once the Web Report Server responds from the Linux host.

Configure a data source and build a report

A successful installation proves only that the software can start. It does not prove that Seal Report can query your data. Configure and run at least one report before publishing the Web Report Server. This isolates driver, credential, query, and schema problems from web-hosting problems.

Keep the initial test intentionally small. A report that scans an entire production table may be slow even when the installation is correct. Apply sensible restrictions, verify indexes and query plans where applicable, and avoid testing remote access with a report that is already known to time out locally.

Seal Report can also use AI agents with a configured provider, including OpenAI, Azure OpenAI, Anthropic, or Ollama. No cloud provider is imposed because a local model can be used. AI functionality is optional and separate from installing the Web Report Server. If you enable it, evaluate what schema information and report data the selected provider can receive, and configure access according to your organization's data-handling requirements.

Publish the Web Report Server through IIS

On Windows, Seal Report provides a Web Server Publisher workflow through Server Manager. IIS must be available and the ASP.NET Core Runtime 10 Hosting Bundle must be installed. The Hosting Bundle supplies the IIS integration needed to host ASP.NET Core applications.

The publication workflow is started in Server Manager through Configuration, then Publish Web Site on IIS.... Complete the Web Server Publisher wizard using settings appropriate for your server. The supplied evidence does not establish a universal site name, host name, application pool, physical destination, IP binding, port, or certificate selection. Record the values you choose because the resulting local URL becomes the target for verification and, later, for Localtonet.

If the site uses an IIS host-name binding, a request sent only to an IP address may not select the intended site. Likewise, publishing beneath an application path means the usable URL may include that path. Test the exact browser address produced by your deployment rather than reducing it to a guessed root URL.

Local-only binding can be a useful way to limit direct network reachability when the Localtonet client runs on the same machine, but binding details depend on IIS and your operational requirements. If our client runs on another device, the Web Report Server must instead listen on an interface reachable from that device. Apply the host firewall and network policy intentionally in either case.

Verify the Web Report Server locally

Local verification is the most important diagnostic checkpoint. A tunnel forwards traffic to an existing service. It does not install Seal Report, start IIS, repair a missing runtime, grant repository access, load a database driver, or correct a report query.

http://LOCAL_HOST:ACTUAL_PORT/OPTIONAL_APPLICATION_PATH

Replace every placeholder with the values from your IIS or Linux hosting configuration. If the site is configured for local HTTPS instead, use the corresponding local HTTPS address and verify that its certificate and binding are valid. Do not assume that Seal Report listens on a particular port simply because another ASP.NET application uses it.

Local verification checklist

• Open the exact site URL from a browser on the Web Report Server host.
• If remote LAN access is intended, open the same service from the device that will run the Localtonet client.
• Confirm that the Web Report Server interface loads without an unhandled error.
• Sign in if your Seal Report configuration requires authentication.
• Navigate to the intended repository folder and open a published report.
• Apply a restriction or filter and execute the report.
• Confirm that the result contains only the intended data.
• Test downloads only if remote users are expected to have download rights.
• Repeat a report execution after restarting the relevant web service or host.

Use the browser's developer tools or a server log if the interface shell loads but report requests fail. A successful initial HTML response does not prove that follow-up API calls, static assets, authentication cookies, downloads, and long-running report requests all work.

Expose the working Web Report Server with Localtonet

After local verification succeeds, an HTTP tunnel can make the Web Report Server reachable through a public HTTPS address. Our client runs on the Seal Report host or another device that can reach it. The client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, a public IP address, firewall changes for inbound internet traffic, or VPN setup.

Use an HTTP tunnel for the browser-facing Web Report Server. Do not publish the database's TCP port as a substitute. The web application should remain the controlled interface through which users access reports, while its configured data-source connections remain on the server side.

HTTP tunnels and File Server tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types, with all three serving content at a public HTTPS address. Availability can vary, and custom-domain DNS requirements must be checked against current dashboard and documentation guidance before configuration. A generated subdomain is the simplest starting point when you only need to verify the end-to-end deployment.

The public address and the local target have separate roles. The public URL is what remote users open. The local target is the private IP address and port our client contacts. Changing the public process type does not repair an incorrect local target, and changing the local IIS binding can require updating the tunnel.

Secure the reporting workflow before inviting users

A public HTTPS address makes the selected web service internet-reachable. It does not decide who should be allowed to view a report. Configure Seal Report authentication, repository rights, per-folder permissions, and report visibility for the intended audience. Do not use possession of an obscure URL as the only access control.

Seal Report 10 introduced granular per-folder rights for report downloads and file uploads, as well as publication of repository folders. Use those controls to separate report audiences and administration functions. A user who only needs to execute a report should not automatically receive administrative, upload, or broad download capabilities.

Use HTTPS consistently

The assigned Localtonet HTTP-tunnel address is public over HTTPS. Seal Report 10.0.1 marks session cookies Secure when the application recognizes an HTTPS request. Reverse-proxy and hosting details can affect how an application interprets the original request scheme, so test authentication and cookie behavior through the public address rather than assuming that a successful local HTTP test is sufficient.

If users are repeatedly signed out or redirected incorrectly, compare the local and public host names, application paths, and request scheme. Do not disable cookie security as a first response. Review the application's supported proxy-facing configuration and the IIS deployment instead.

Review report content as exposed data

Report output can contain personal, financial, operational, or customer information even if the source database remains private. Test with an account that has the same rights as an ordinary remote user. Confirm that report filters cannot be removed to reveal a broader data set and that exports do not contain hidden columns or unrestricted detail.

Scheduled reports deserve the same review. Seal Report can write results to folders, FTP or SFTP servers, SharePoint document libraries, or send them through supported email providers. Those destinations are independent of the HTTP tunnel and require their own credential management, retention policy, and access controls.

Operate the tunnel intentionally

Start the tunnel only when the service is ready for remote use. Stop it during maintenance if users should not reach the server. Delete obsolete tunnels, protect the device-specific token, and verify that the selected client device is still the intended execution point. Localtonet can be managed from the dashboard or REST API, but API automation should use secrets handling appropriate to the environment and should never embed credentials in report output.

Troubleshoot installation, publication, and tunnel failures

The installer completes, but Report Designer does not open

Verify Microsoft Windows Desktop Runtime 10 and Microsoft Edge WebView2. Confirm that the installed runtime matches the Seal Report release requirements. If Windows reports a missing framework or component, resolve that prerequisite before reinstalling repeatedly. Also confirm that endpoint-security software has not quarantined an installed executable.

Server Manager works, but IIS returns a startup error

Check that IIS is installed and that the ASP.NET Core Runtime 10 Hosting Bundle is present. Confirm that the Web Report Server was published through the Server Manager's Configuration and Publish Web Site on IIS... workflow. Review the IIS application and operating-system logs for the concrete runtime, module, file-access, or process-start failure.

Repository permissions are also important. The IIS-hosted process must be able to access the repository resources required by the application, but it should not receive broad unrelated file-system privileges. Use the identity selected by the publication configuration and grant only the documented access it needs.

The interface loads, but no data appears

Return to Server Manager and Report Designer. Verify the data-source driver, connection settings, source availability, and reporting account permissions. Run a minimal report locally. If the source requires TLS, a client certificate, a provider-specific option, or name resolution, fix that at the data-source layer.

Distinguish an empty valid result from a failed query. Restrictions, date ranges, security filters, and joins can legitimately return no rows. Validate the same conditions against known test data rather than broadening production access merely to make the report display something.

The local site works, but the Localtonet public address does not

First confirm that the Localtonet client is connected and that the tunnel has been started. Next inspect the local IP and port configured in the tunnel. Test that exact target from the machine running our client. If the client runs on another device, localhost refers to that other device, not to the Seal Report server.

Verify that a host-name binding or application path is not being omitted. If IIS expects a particular host name, requests addressed differently may select another site or fail. Do not change several layers at once. Prove the target from the client device, then test the public address.

The public page opens, but styles, scripts, or report actions fail

This often indicates an application-path, generated-URL, host-name, scheme, or proxy-facing issue rather than basic connectivity. Compare failed browser requests with the successful document request. Check whether the application produces local-only URLs, redirects to a different host, or omits the published application path.

Authentication loops or sessions do not persist

Test with a clean browser session and use one consistent public URL. Confirm that cookies are accepted and that redirects remain on the expected host and HTTPS scheme. Seal Report 10.0.1 includes secure-cookie behavior on HTTPS, so make sure the application correctly recognizes the externally secure request. Consult the applicable Seal Report hosting guidance before changing security-sensitive settings.

Reports are slow remotely

Compare local and remote execution time. If report generation is already slow locally, optimize the report, restrictions, joins, source query, or database indexes first. If generation is fast but a large result is slow to transfer, reduce unnecessary columns and rows, choose an appropriate output, and avoid using an interactive browser report as an unlimited bulk export mechanism.

An upgrade breaks charts or custom views

For Seal Report 10, replace NVD3 charts with a supported engine such as ECharts or ChartJS. Review custom Bootstrap 3 views and templates against the Bootstrap 5 versions. Back up the repository and custom files before upgrading, and test the new version in a non-production environment where possible.

Frequently asked questions