Self-Host DramaClaw with Remote Access via Localtonet

What you are self-hosting

DramaClaw is described by its project as a source-available, general-purpose AIGC video engine. Its purpose is broader than generating a single image or clip. It combines creative planning, reusable assets, generative media tasks, and video composition into a production workflow that can move from a script or manuscript toward a finished visual story.

The application has two main working surfaces that share an asset library and an agent. XiaHua is an infinite, node-based canvas for creating, editing, connecting, and arranging images, video, audio, scripts, and 3D material. Series, also called XiaJi, is the structured pipeline. It handles work such as story organization, episode planning, script development, storyboards, first frames, voice-over, and final assembly.

Xia Director operates across those surfaces. It can interpret a natural-language creative brief, help plan a workflow, coordinate nodes, inspect project progress, and drive supported pipeline tasks. The project also describes a workflow catalog with skills and recipes for formats including short drama, e-commerce advertising, character advertising, and social content. Some capabilities, including the in-browser 3D previs stage and interactive stories, are identified by the project as closed beta features. They should not be treated as generally available merely because they appear in the project overview.

A self-hosted deployment gives you operational control over the machine, container lifecycle, storage, and network exposure. It does not automatically make every connected AI model local. A workflow may still call model providers or other services according to the configuration you choose. Review every provider, credential, and data flow before processing confidential scripts, customer material, unreleased footage, or licensed assets.

Prerequisites and decisions to make first

The verified project material establishes Docker as the documented deployment direction, but the supplied Quick Start excerpt does not establish an operating-system matrix, minimum Docker version, Compose version, CPU requirement, memory requirement, GPU requirement, supported accelerator, storage estimate, or service port. We therefore cannot safely publish numerical requirements or platform promises in this draft.

Before installation, prepare a host on which the current Docker and Docker Compose tooling works. You also need enough disk capacity for the application, container images, project assets, generated media, caches, and any model-related data used by your chosen workflow. Video production can create substantially larger working sets than a conventional web application, but no evidence-backed capacity estimate is available here. Size the host according to your own source media, output resolution, retention policy, and model configuration.

Confirm the following before proceeding:

• A host where you are authorized to install and run containers.
• A current copy of the official DramaClaw repository or a deliberately selected release.
• The current DramaClaw Quick Start open for the exact commands and values associated with that revision.
• Persistent storage and a backup plan for irreplaceable project material.
• Credentials for any external model or media services you elect to configure.
• A modern browser for testing the application locally.
• A Localtonet client device that can reach DramaClaw when remote access is required.
• Authority to expose the selected instance and its content beyond the local machine.

Install DramaClaw with its official Docker workflow

The safe installation path is to use the Quick Start that belongs to the exact DramaClaw revision you intend to run. The repository visibly contains a Dockerfile, docker-compose.yml, docker-compose.release.yml, docker-compose.brainclaw-evidence.yml, and .env.example. Their presence is useful evidence that the project supports container deployment, but it does not tell us which Compose file, profile, build argument, environment file, or command the current Quick Start selects.

This distinction is important. Running a plausible generic command against an arbitrary Compose file could build a development image instead of a release image, omit required services, use unintended defaults, or publish a different port. For that reason, this article does not substitute an invented docker compose command for the missing official instructions.

1. Choose a revision intentionally

Decide whether you want the project’s current default branch or a named release. A named release can make an installation easier to reproduce because the application code and deployment files remain tied to a specific revision. The supplied evidence identifies v2.0.6 as a release and describes user-facing changes such as canvas video extension, model-backed video resolution and frame-rate enhancement, and MP3 output from audio separation.

Those release features have configuration dependencies. Video extension requires a compatible configured model, and enhancement is model-backed. Installing the application alone does not guarantee that every workflow or release feature can run. Treat model setup as a separate configuration and validation task.

2. Obtain the official project files

Retrieve the repository using the method documented by the project for the chosen revision. Confirm that the expected Docker, Compose, environment example, source, and documentation files are present before running anything. If files are missing or differ materially from the Quick Start, stop and reconcile the revision rather than combining instructions from different versions.

3. Read the selected Compose definition before starting it

Inspect the exact Compose file named by the current Quick Start. Identify its services, image or build source, published ports, mounted directories, named volumes, environment inputs, restart behavior, dependencies, and any optional profiles. This review establishes what will run and where persistent data is expected to live.

In particular, record the host-side published port. A container’s internal port is not automatically the port that a browser or Localtonet should use. When a mapping contains two port values, the host-side value is the one reached from the host. Do not assume a conventional web port when the project documentation or container output provides the real value.

4. Create configuration only as directed

Use the project’s current Quick Start to determine whether .env.example should be copied, renamed, or used only as a reference. Review each documented setting before entering a value. Preserve variable names exactly, and do not add guessed variables copied from old issues, unofficial examples, or a different release.

Separate ordinary settings from credentials. If the selected model integration requires a key, limit its permissions and usage according to the provider’s controls. Avoid reusing credentials from a production environment while evaluating the application. Keep the populated configuration outside public repositories and backups that are not designed to protect secrets.

5. Run the exact Quick Start command

Execute the Docker command shown in the current official Quick Start for your selected revision. The exact command is a material installation detail, and it is absent from the supplied evidence, so it cannot be reproduced responsibly here. Watch the initial output for image download or build failures, missing variables, unavailable ports, volume permission errors, dependency failures, and the address exposed by the web service.

Do not create a Localtonet tunnel at this stage. First prove that the containers remain running and that the application can be opened from the same machine or local network. This separation makes troubleshooting much easier because it prevents an application problem from being mistaken for a tunnel problem.

Configure the creative environment

A successful container start proves only that the application process launched. DramaClaw’s useful production capabilities depend on the models, services, storage, and workflow components selected for the project. Configure incrementally so that a failure can be traced to one integration instead of a large collection of changes.

Start with the smallest testable workflow

Open the local interface and create or select a non-sensitive test project. Confirm that the basic UI loads before adding external model credentials. Then configure one supported provider or model at a time, using the current project instructions for that integration. Run a minimal task and retain its logs until you know the integration works.

Avoid beginning with a full multi-stage production. A long workflow can involve script processing, image generation, audio synthesis, video generation, enhancement, and composition. If several integrations are introduced simultaneously, an error near the end may hide a much earlier configuration problem.

Separate application readiness from model readiness

Use three different readiness states when evaluating the deployment:

• Container readiness: the required containers start and remain running.
• Interface readiness: the browser UI loads at the documented local address.
• Workflow readiness: the configured model or provider successfully completes a small task and returns an expected asset.

This separation is particularly relevant to v2.0.6 features. The release says that video extension works when a compatible model is configured and that resolution or frame-rate enhancement is model-backed. If the interface offers a control but execution fails, investigate the selected model and its configuration before assuming that Docker networking or Localtonet is responsible.

Plan persistence before creating valuable work

Determine which host directory or Docker volume holds projects, assets, generated media, and application state. The verified excerpt does not identify those paths, so inspect the selected Compose definition and current documentation. Back up the persistent data rather than only the container image or repository checkout.

A useful recovery test is more valuable than an untested backup job. On an isolated host or temporary environment, confirm that the documented restore process recreates a project and its linked assets. Do not experiment with restoration against the only copy of active production data.

Verify DramaClaw locally before remote access

Local verification creates a clear boundary between DramaClaw setup and network publication. If the application does not work at its local address, an HTTP tunnel will not repair it. It will only forward requests toward an unhealthy, incorrect, or unreachable target.

Use the host address and published port established by the official Quick Start or the selected Compose configuration. Do not copy a port from an unrelated tutorial. Open that exact address in a browser from the DramaClaw host. If the service is deliberately bound to a LAN interface, you can also test from another authorized device on the same network.

Local acceptance checklist

• The expected containers are running rather than repeatedly restarting.
• The web address opens without a connection refusal or indefinite timeout.
• HTML, scripts, styles, icons, and other browser assets load correctly.
• Navigation within the canvas and project interface works after a refresh.
• A small test project can be created or opened according to the application workflow.
• At least one deliberately configured model integration completes a minimal test, if model execution is part of your intended use.
• Generated output is written to persistent storage rather than disappearing when a container is recreated.
• The browser developer console and container logs do not show recurring configuration or network failures.

Record the exact working local target as an IP address and port. For example, the target might be a loopback address when Localtonet runs on the same host, or a private LAN address when the Localtonet client runs on another device. These are architectural examples, not DramaClaw defaults. Use only the address and port proven in your environment.

Publish the verified interface with a Localtonet HTTP tunnel

After DramaClaw works locally, an HTTP tunnel can expose its browser interface through a public HTTPS address. The Localtonet client establishes an outbound connection to one of our relay servers, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

The tunnel remains dependent on both sides of the local deployment. DramaClaw must be running, and the selected Localtonet client device must remain connected with the tunnel started. Creating a tunnel configuration does not start it automatically.

Availability can vary by plan, client version, region, and current product configuration. Obtain the available relay servers and options from the current dashboard instead of copying a server code from an article. For custom domains, check the current Localtonet documentation before making DNS changes because exact requirements are not established in the supplied context.

Configure and start the tunnel

You can review the current workflow in the Localtonet HTTP tunnel documentation. Use the documentation and dashboard values that are current for your client and account rather than hardcoding an example relay server or public hostname.

Verify more than the landing page

A landing page can load even when interactive functions fail. After the public address opens, test project navigation, canvas loading, ordinary API requests initiated by the browser, and one small non-sensitive operation. Refresh a nested view to detect path-handling issues. If the UI uses long-running tasks, observe one test task without assuming that every external provider will behave identically over a remote session.

Keep the local browser test available during diagnosis. If an action fails locally and publicly, investigate DramaClaw or its model integration. If it succeeds locally but fails only through the public address, compare browser errors, request paths, application logs, and the local target selected in the tunnel.

Secure remote creative access

A public URL changes the risk profile of a self-hosted application. It can make the interface reachable from outside the trusted local network, so remote access should be a deliberate operational decision rather than the default state of every installation.

The supplied DramaClaw evidence does not establish whether the selected release provides built-in user authentication, role-based access, session controls, or network allowlists. Do not assume that these protections exist. Inspect the current application documentation and test the actual deployment before exposing projects or provider-backed actions.

Remote access also does not change the terms of the DramaClaw license. Operating your own remotely accessible instance is distinct from packaging the application as a hosted SaaS for other people. If the deployment is part of a commercial service, obtain a qualified review of the current license and project notices.

Routine operation, updates, and recovery

Starting a working session

Start the Docker deployment with the command documented for your installed revision. Confirm that all required containers remain healthy and open the local interface. Start the Localtonet client, verify that the correct device is connected, and then start the existing HTTP tunnel. Open the public address only after the local service is ready.

Ending a working session

Finish or pause active generation tasks according to DramaClaw’s current behavior before stopping containers. Confirm that project changes and generated assets have reached persistent storage. Stop the Localtonet tunnel when public access is no longer needed, then stop DramaClaw using the official command for the selected deployment.

Updating DramaClaw

Treat an update as a controlled change rather than replacing containers without preparation. Read the release notes between your current revision and the target revision. Back up persistent data and the active configuration, but keep secret-bearing files protected. Check for changes to Compose files, environment variables, volumes, provider integrations, workflow schemas, and browser behavior.

After the update, repeat local verification before restarting the public tunnel. Confirm that existing projects open, assets resolve, a minimal workflow completes, and the local address or published port has not changed. If the host port changed, update the Localtonet tunnel target only after testing the new endpoint locally.

Backing up the right material

A repository checkout is not necessarily a backup of creative work. Identify the persistent volumes and host directories used by the selected deployment. Include project metadata, source assets, generated outputs, reusable workflow definitions, and any other state required by the documented restore process.

Store credentials separately according to your security policy. A data restore may require secrets to be re-entered rather than copied from an old environment. Document that dependency without recording actual keys in the recovery checklist.

Monitoring availability

Remote availability depends on several independent components: the DramaClaw application, its containers and dependencies, the local host, the network path from the Localtonet client to the application, the connected Localtonet device, and the running tunnel. A failure in any one of these can make the public interface unavailable.

When diagnosing an outage, test from the inside outward. Check containers first, then the local browser endpoint, then reachability from the Localtonet client device, then device connectivity, tunnel state, and finally the public address. This order reduces guesswork and avoids recreating a correct tunnel to compensate for a stopped application.

Troubleshooting DramaClaw and remote access

Port conflicts

If Docker reports that a port is already allocated, identify the process or container using that host port. Do not choose an arbitrary replacement without checking how the project expects its browser endpoint and internal services to communicate. If the official documentation permits changing the host-side port, make the change there, restart, verify locally, and then update the Localtonet target.

Container restart loops

Repeated restarts commonly indicate that the main process exits during initialization. Read the first relevant error rather than only the final restart message. Check for missing configuration, inaccessible storage, incompatible files, or an unavailable dependency. Avoid deleting volumes as a first response because that can remove project state.

Model-backed feature failures

A visible feature does not prove that its supporting model is configured. For example, the v2.0.6 release describes video extension only when a compatible model is available and identifies enhancement as model-backed. Validate provider access and model compatibility using the current project instructions. Never send a real credential to an unknown diagnostic service.

Public endpoint shows the wrong service

Verify the local IP address and host port in the HTTP tunnel. On machines running several web applications, a nearby port can belong to an unrelated dashboard. Open the target directly from the Localtonet client device and confirm that it displays DramaClaw before restarting the tunnel.

Frequently asked questions