How To Host A Web Server On Android

What hosting a web server on Android means

A web server is a process that listens for HTTP requests on a network port and returns files or generated responses. In this tutorial, that process runs inside Termux and listens on an unprivileged port such as 3000, 5000, or 8080. A browser on the same Android device can access it through an address such as http://127.0.0.1:8080.

The address 127.0.0.1 is the IPv4 loopback address. Binding a server to it limits direct connections to applications on the same device. This is preferable to binding a temporary development server to 0.0.0.0, which can make it reachable from other devices on the same Wi-Fi network. Our Android client can still connect to the loopback service because the client and server run on the same phone.

Local access does not automatically provide internet access. Mobile carriers commonly place devices behind carrier-grade NAT, while Wi-Fi networks usually place them behind a router. Localtonet solves that connectivity problem by having the Android client establish an outbound connection to one of our relay servers. After an HTTP tunnel is created and started, requests follow this path:

Public browser
      |
      | HTTPS request
      v
Localtonet public endpoint
      |
      | Existing outbound tunnel connection
      v
Localtonet Android client
      |
      | HTTP request to 127.0.0.1 and the configured port
      v
Python, Express, or Flask server inside Termux

The local application remains on the phone. The tunnel supplies a public route to it while the selected Android client is connected and the tunnel is running. Creating a tunnel configuration does not start it automatically, and a saved tunnel does not remain reachable if Android terminates either Termux or the Localtonet client.

Prerequisites and a safe Termux installation

You need an Android device capable of running a current Termux build, sufficient storage for your packages and project, internet access for package installation, a Localtonet account, and the official Localtonet Android application. The examples use user-space ports and do not require root access.

Install Termux from a maintained official source

Follow the official Termux installation guidance before installing the application. Current Termux builds support Android 7.0 or later. Older Android releases are not supported by the current application and package ecosystem in the same way, so an obsolete APK is not a suitable foundation for an internet-facing project.

For most users, the official guidance recommends the Termux package on F-Droid, preferably installed through the F-Droid client so update notifications and normal package updates are available. Official GitHub releases are another documented installation path, but users must choose the correct APK and understand that GitHub builds use their own signing source.

Open Termux after installation and update its package metadata before adding tools:

pkg update
pkg upgrade

Read the proposed package changes before accepting them. The examples in this guide store projects under the Termux home directory, so they do not need access to Android shared storage. If you intentionally need shared storage, run termux-setup-storage and approve the Android permission prompt. Granting that permission increases the set of files Termux can reach, so continue to serve only a dedicated project directory.

Install and prepare the Localtonet Android client

Install the official Localtonet application from Google Play. Register for an account if needed, then create or obtain the device-specific AuthToken from your Localtonet account. Enter that token into the Android client to authenticate the device. The AuthToken identifies the client that will run the tunnel, so treat it as a credential.

Keep the Android application open during initial setup and confirm that the authenticated device appears as connected in our dashboard. Do not paste the AuthToken into source code, shell history examples, screenshots, public issue reports, or files served by the web application. If a real token is exposed, stop using it and replace it through the account workflow rather than attempting to conceal only the published copy.

Choose one local port

Create a web server in Termux

Choose one of the following methods. You do not need to run all three. Python's built-in server is the shortest route to a static page, Express provides a basic JavaScript API, and Flask provides a basic Python application. Each example binds explicitly to 127.0.0.1.

Method 1: Serve a static website with Python

Python includes a simple HTTP server that is useful for local development and temporary demonstrations. It does not provide application authentication, detailed authorization, production hardening, or a complete operational logging system. Serve only a dedicated directory containing files you intentionally want visitors to access.

pkg update
pkg install python

mkdir -p ~/android-site
cd ~/android-site
nano index.html

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Android Test Server</title>
</head>
<body>
  <h2>Android server is running</h2>
  <p>Served from Termux with Python.</p>
</body>
</html>

cd ~/android-site
python -m http.server 8080 --bind 127.0.0.1

Method 2: Run a Node.js and Express API

This Express example provides two routes and suppresses the default X-Powered-By header. It is still a learning example rather than a complete production API. A real application needs authentication, authorization, request validation, appropriate request-size limits, dependency review, safe error handling, and its own logging policy.

pkg update
pkg install nodejs-lts
node -v
npm -v

mkdir -p ~/myserver
cd ~/myserver
npm init -y
npm install express

nano server.js

const express = require('express');
const app = express();

app.disable('x-powered-by');

app.get('/', (req, res) => {
  res.json({ message: 'Android server is running' });
});

app.get('/api/status', (req, res) => {
  res.json({ status: 'ok', platform: 'android' });
});

app.listen(3000, '127.0.0.1', () => {
  console.log('Server running at http://127.0.0.1:3000');
});

cd ~/myserver
node server.js

Method 3: Build a small Flask application

Flask is useful for learning Python web development and building prototypes. Flask's built-in server is explicitly a development server. It should not be treated as a hardened production server, particularly when an application handles private information, credentials, uploads, administrative functions, or untrusted input.

pkg update
pkg install python
python -m pip install flask

mkdir -p ~/flaskapp
cd ~/flaskapp
nano app.py

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/')
def home():
    return '<h2>Hello from Android</h2>'

@app.route('/api/status')
def status():
    return jsonify({'status': 'running', 'platform': 'android'})

if __name__ == '__main__':
    app.run(host='127.0.0.1', port=5000, debug=False)

cd ~/flaskapp
python app.py

Verify the server locally before creating a tunnel

Separate local application testing from tunnel testing. If the application does not answer on 127.0.0.1, changing the relay server, public hostname, or tunnel Process Type will not repair it. First confirm that the process is running, then request the exact route you intend to expose.

Stage 1: Confirm that the process is still running

Return to the Termux terminal where the server was started. A running foreground process normally keeps control of that terminal. If the shell prompt has returned, read the error shown above it. Typical causes include a syntax error, missing dependency, incorrect working directory, or a port already in use.

Install the standard networking and HTTP test tools if they are not already present:

pkg install iproute2 curl

Inspect listening TCP sockets:

ss -ltn

Look for the selected loopback address and port, such as 127.0.0.1:8080, 127.0.0.1:3000, or 127.0.0.1:5000. A listening socket confirms that a process has opened the port, but it does not prove that the application returns the correct content.

Stage 2: Check the expected application response

Open a second Termux session or use the Android browser while the server remains running. Test the matching example:

Python static server:

curl -i http://127.0.0.1:8080/

Expect an HTTP success response and HTML containing Android server is running. If a directory listing appears instead, verify that index.html exists in ~/android-site and that the server was started from that directory.

Express API:

curl -i http://127.0.0.1:3000/api/status

Expect an HTTP success response with JSON containing "status":"ok" and "platform":"android". Also test the root route if it will be shared:

curl -i http://127.0.0.1:3000/

The root response should contain "message":"Android server is running".

Flask application:

curl -i http://127.0.0.1:5000/api/status
curl -i http://127.0.0.1:5000/

The status route should contain "status":"running" and "platform":"android". The root route should return the Hello from Android heading.

Configure the Localtonet HTTP tunnel

Our Android client must run on the Android device hosting the Termux server. It establishes the outbound relay connection, so this workflow does not require an inbound router rule, a public IP address, a firewall exception, or a VPN. Complete the local verification first, then follow the HTTP tunnel sequence below.

Understand the three HTTP Process Types

Do not assume that every Process Type, relay, hostname choice, or access-control option is included with every account or subscription. Use the choices displayed in the current dashboard. For a Custom Domain, follow the DNS values shown there rather than copying nameservers or records from an older article. DNS requirements and account availability can change.

Verify the public HTTPS endpoint in stages

A public test should prove more than the presence of a hostname. Verify the Android client, tunnel state, response content, and external network path separately. This makes it easier to distinguish an application failure from a tunnel failure.

An HTTP error generated by the application, such as a route-specific 404, shows that a request reached a web server but requested the wrong path. A connection failure at both the local and public addresses usually points to the application. A working local response combined with a failed public response points toward the client connection, tunnel state, selected AuthToken, relay configuration, or public access controls.

Run, stop, maintain, and recover the service

Android can suspend or terminate applications to conserve battery and memory. A terminal multiplexer makes routine shell management easier, but it cannot override Android's process lifecycle. Treat both the Termux server and Localtonet tunnel as processes that may need to be checked and restarted.

Manage the server with tmux

pkg install tmux

tmux new -s myserver

node ~/myserver/server.js

tmux ls
tmux attach -t myserver

Stop the local server safely

Reattach to the tmux session and press Ctrl+C in the terminal running the server. Wait for the shell prompt to return, then confirm that the port is no longer listening:

ss -ltn

To terminate an entire tmux session after the application has stopped, run:

tmux kill-session -t myserver

Avoid immediately killing the session while an application is writing files or processing a request. A normal interrupt gives the process an opportunity to exit cleanly. If a process does not respond, diagnose it before escalating to forced termination.

Review output and keep simple logs

Reattach with tmux attach -t myserver to review live application output. You can also print the visible tmux pane without attaching:

tmux capture-pane -p -t myserver

For a temporary development session, redirect standard output and errors through tee:

cd ~/myserver
node server.js 2>&1 | tee -a server.log

The same pattern can be used with python app.py. Logs can contain request paths, application errors, submitted values, or other sensitive material, so store them in the private project directory, review their contents before sharing, and remove them when no longer required. Python's simple HTTP server writes basic request information to its terminal output.

Recover after Android stops an application

If Android terminates Termux, the tmux server ends with it. Reopen Termux, run tmux ls, and do not assume the session survived. If no session exists, create a new one, change to the correct project directory, and restart the application using the original command. Verify the loopback endpoint again before relying on the public URL.

If Android terminates the Localtonet client, reopen it and confirm that the device reconnects. Then check the saved tunnel. Depending on its current state, you may need to press Start again. A connected device and a running local server are both required, but neither alone proves that the tunnel is running.

Network transitions can also interrupt connectivity. When moving between Wi-Fi and mobile data, allow the Android client to reconnect, confirm the tunnel state, and repeat both the local and public tests. Do not diagnose DNS or rewrite application code until you have checked those states.

If the device provides per-application battery controls, review them for both Termux and Localtonet while the service is needed. Labels and behavior vary by Android release and manufacturer. Avoid force-stopping either application, and test the actual device instead of assuming that a battery setting guarantees continuous operation.

Update dependencies deliberately

Stop the server before a maintenance update. For Termux packages, review and apply available updates:

pkg update
pkg upgrade

For the Express project, inspect outdated packages and the audit report before deciding what to change:

cd ~/myserver
npm outdated
npm audit

Apply compatible updates deliberately, test the application locally, and retain the lock file. Do not apply an automatic breaking upgrade immediately before a public demonstration.

For Flask, inspect the environment with:

python -m pip list --outdated
python -m pip check

Update packages only after reviewing compatibility with the application. Restart the service and repeat the local response tests after every dependency change.

Remove public access when finished

Cleanup should happen in this order: press Stop for the Localtonet tunnel, confirm that the public address no longer serves the application, stop the local server with Ctrl+C, and delete the saved tunnel if it will not be reused. Deleting a tunnel is different from stopping it. Stop preserves the configuration for later use, while deletion removes that saved tunnel from the account.

Use a custom subdomain or custom domain carefully

Random Sub Domain, Custom Sub Domain, and Custom Domain Process Types all deliver the selected local HTTP service through a public HTTPS address. A generated subdomain is usually the simplest choice for temporary testing. A custom subdomain provides a more recognizable Localtonet-hosted name where supported. A custom domain connects a hostname you control.

Custom-domain configuration requires DNS changes. Select Custom Domain in the current workflow and use the exact DNS instructions displayed by our dashboard or current documentation. Do not copy DNS records, nameservers, or certificate instructions from an old tutorial. Wait for the required DNS changes to propagate before treating a hostname failure as an Android application problem.

Availability can vary by account, plan, client version, and current product configuration. Check the dashboard before designing a workflow around a particular hostname option. Do not assume that a custom subdomain or custom domain will be available for every account.

Secure the service before public exposure

A public tunnel changes who can send requests to the application. Treat every public request as untrusted internet traffic, even when the URL was shared with only one person. URLs can be copied, logged, forwarded, stored in browser history, or discovered through an unintended disclosure.

Basic Authentication and IP whitelisting

The current Localtonet Android application listing documents Basic Authentication and IP whitelisting as access-control capabilities. Basic Authentication can place a username and password check in front of the public endpoint. IP whitelisting can restrict requests to approved source IP addresses. Use the current controls shown for your tunnel because option placement and availability can vary by account or product version.

Test restrictions from both an allowed and a disallowed client before relying on them. An IP allowlist can be inconvenient when an approved user's public address changes, especially on mobile or residential networks. Basic Authentication credentials must be strong, private, and transmitted only through the HTTPS endpoint.

Protect secrets and user input

Keep API keys, Localtonet AuthTokens, database credentials, and private endpoints outside publicly served files. Do not embed secrets in JavaScript delivered to the browser. Never put a Localtonet AuthToken in index.html, application responses, screenshots, or a public source repository.

Validate request bodies, parameters, file names, and content types. Limit uploads and request sizes where the framework supports it. Avoid constructing shell commands, paths, database queries, or template expressions directly from user-supplied values. Return controlled error messages rather than stack traces or environment details.

Python's simple HTTP server and Flask's development server remain development tools even when the public endpoint uses HTTPS and access controls. HTTPS protects traffic to the public endpoint, but it does not add missing authorization, harden a development server, remove vulnerable dependencies, or prevent the application from serving the wrong files.

Troubleshooting Android server and tunnel failures

Distinguish application failures from tunnel failures

An application failure appears at the loopback address. Examples include a refused connection, Python serving the wrong directory, an Express exception, or a Flask route returning an error. Read the local process output and fix that condition before investigating Localtonet.

A tunnel-side failure occurs when the expected local request works but the same path does not work through the public HTTPS endpoint. Check the connected AuthToken, Android client state, tunnel state, selected relay, target IP and port, Process Type, and access controls. If the phone recently changed networks, allow the outbound connection to recover and retest.

Frequently asked questions