# How to Manage Users in LingBot-Map: A Practical Guide to Multi-User Environments > Learn how to manage users in LingBot-Map by leveraging OS-level isolation like Conda and Docker for secure multi-user environments. This practical guide details essential strategies. - Repository: [Robbyant/lingbot-map](https://github.com/Robbyant/lingbot-map) - Tags: how-to-guide - Published: 2026-07-19 --- **LingBot-Map does not implement built-in user authentication or account management, so administrators must rely on OS-level isolation strategies such as Conda environments, Docker containers, and file permissions to manage multi-user access safely.** LingBot-Map is a research-focused Python library that provides streaming 3D reconstruction capabilities. Because the codebase is designed for command-line execution rather than multi-tenant web services, it lacks internal user management features entirely. Consequently, any organization deploying LingBot-Map across multiple users must implement external controls for environment isolation, credential management, and file-system permissions. ## Understanding the User Model in LingBot-Map The concept of a "user" in LingBot-Map is strictly limited to the individual executing the command-line tools. The repository contains no user-account database, session management, or authentication logic. All interaction occurs through standalone scripts that parse arguments directly from the shell. In [`demo.py`](https://github.com/Robbyant/lingbot-map/blob/main/demo.py), the entry point reads flags such as `--model_path`, `--image_folder`, and `--config` without any verification of user identity. Similarly, [`demo_render/batch_demo.py`](https://github.com/Robbyant/lingbot-map/blob/main/demo_render/batch_demo.py) operates as an offline rendering pipeline that trusts the underlying operating system to enforce access controls. This design keeps the codebase lightweight and reproducible but shifts all user-management responsibilities to the host environment. ## CLI Entry Points and Configuration LingBot-Map exposes functionality through two primary scripts that accept YAML configuration files and directory paths as inputs. ### Command-Line Invocation The main interactive demo resides in [`demo.py`](https://github.com/Robbyant/lingbot-map/blob/main/demo.py), which users invoke with arguments like: ```bash python demo.py --model_path /path/to/model.pt --image_folder example/oxford --mask_sky ``` The batch processing variant in [`demo_render/batch_demo.py`](https://github.com/Robbyant/lingbot-map/blob/main/demo_render/batch_demo.py) follows the same pattern, accepting paths and rendering parameters without user profiling. ### Configuration File Handling Users can supply a YAML config via the `--config` flag to control rendering quality, camera paths, and post-processing options. The configuration at [`demo_render/config/indoor.yaml`](https://github.com/Robbyant/lingbot-map/blob/main/demo_render/config/indoor.yaml) is read verbatim from disk with no per-user layering or profile merging. This means that if multiple users require different rendering settings, they must maintain separate configuration files on the file system rather than relying on the application to select profiles based on identity. ## File System and Cache Management LingBot-Map generates temporary artifacts that require careful permission management in multi-user deployments. ### Cache Directory Structure By default, the library stores sky-mask caches and intermediate files in a subdirectory appended to the input image folder, specifically `_sky_masks/`. Alternatively, users can redirect cache storage using the `--sky_mask_dir` argument. Because these paths are simple directories on disk, access control is governed entirely by standard Linux file permissions (`chmod`, `chown`) rather than application-level security policies. ### Permission Best Practices When multiple users share a compute node, administrators should ensure that cache directories are owned by the process owner. For collaborative projects, export final reconstructions to a common output folder with group write permissions while keeping intermediate caches user-private to prevent file-locking conflicts. ## External Credentials and Dependencies LingBot-Map relies on external libraries such as **FlashInfer**, **PyTorch**, and **Kaolin**, which may require their own authentication credentials. ### Managing API Tokens The repository does not provide internal credential storage. For example, downloading pretrained models from HuggingFace requires a valid token set via the `HF_TOKEN` environment variable. The source code never reads or logs this variable, complying with security best practices, but this also means administrators must handle token distribution outside the repository. Set tokens in a per-user shell configuration that remains uncommitted: ```bash # In ~/.bashrc or ~/.bash_profile export HF_TOKEN="hf_XXXXXXXXXXXXXXXXXXXX" ``` This approach ensures that each user accesses the model repository with their own credentials without exposing keys in shared codebases. ## Practical Multi-User Management Strategies Because LingBot-Map delegates user management to the operating system, implement the following architectural patterns to support multiple researchers or operators safely. ### Isolate Execution Environments Create dedicated Conda environments for each user to prevent dependency version clashes. This isolation ensures that one user's PyTorch or FlashInfer upgrade does not break another's pipeline. ```bash # Create and activate a per-user environment conda create -n lingbot-map-jane python=3.10 -y conda activate lingbot-map-jane # Install the repository in editable mode pip install -e . ``` ### Deploy Containerization Docker provides stronger isolation by encapsulating the entire toolchain including CUDA drivers and system libraries. Build an image once and run containers under distinct Unix user IDs to enforce file-system separation. ```bash # Build the image docker build -t lingbot-map:latest . # Run as a specific user (uid 1001) docker run -it --gpus all \ -u 1001:1001 \ -v /shared/data:/data \ lingbot-map:latest \ bash -c "python demo.py --model_path /data/models/lingbot-map.pt \ --image_folder /data/example/courthouse --mask_sky" ``` ### Enforce Version Locking To prevent accidental upgrades that break reproducibility, tag a specific commit (e.g., `v1.2.0`) and instruct all users to checkout that tag. This practice ensures that every user operates against the same codebase defined in [`pyproject.toml`](https://github.com/Robbyant/lingbot-map/blob/main/pyproject.toml) and documented in the [`README.md`](https://github.com/Robbyant/lingbot-map/blob/main/README.md). ## Summary - **LingBot-Map has no internal user management**: Authentication and authorization must be handled by the host operating system or container orchestration platform. - **Entry points are CLI-only**: Both [`demo.py`](https://github.com/Robbyant/lingbot-map/blob/main/demo.py) and [`demo_render/batch_demo.py`](https://github.com/Robbyant/lingbot-map/blob/main/demo_render/batch_demo.py) accept arguments directly without user profiling. - **Caches are file-system dependent**: Sky-mask directories (`_sky_masks/`) rely on OS permissions for access control. - **External credentials are operator-managed**: Set `HF_TOKEN` and similar variables in per-user shell profiles, never in the repository. - **Isolation is essential**: Use Conda environments or Docker containers to separate dependencies and prevent conflicts between users. ## Frequently Asked Questions ### Does LingBot-Map support user authentication? No. The repository under the Apache-2.0 license contains no authentication logic, session handling, or user database. All security boundaries must be enforced by Linux user accounts, file permissions, or container runtimes. ### How do I isolate multiple users on a shared server? Create separate Conda environments per user (e.g., `conda create -n lingbot-map-`) or deploy Docker containers with distinct Unix UIDs. This prevents library version conflicts and ensures that temporary caches in `_sky_masks/` directories do not collide between users. ### Where are user-specific caches stored? By default, caches are written to `_sky_masks/` relative to the input data path, or to a custom location specified via `--sky_mask_dir`. These are standard directories governed by file-system permissions, not user-specific database records. ### How should I handle HuggingFace API tokens for different users? Each user should export their own `HF_TOKEN` environment variable in their private shell configuration (e.g., `~/.bashrc`). The LingBot-Map source code never reads configuration files for secrets, so administrators must distribute credentials through external, secure channels outside the repository.