Build a local Sixb workspace, verify its generated services, and publish only the endpoint you intend to share
Sixb is an open-source TypeScript framework for building ontology-powered applications and AI around a shared domain model. Its Bun quickstart creates a development project without requiring initial database setup or API keys. This guide covers installing Bun, scaffolding Sixb, discovering and verifying the URLs produced by the generated project, operating and upgrading it carefully, and exposing one selected HTTP service through Localtonet. Our client establishes an outbound connection to a Localtonet relay, so you do not need inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
📋 What's in this guide
Understand the services in a Sixb development project
Sixb describes itself as a TypeScript framework for ontology-powered applications and AI. A project defines its domain in TypeScript, including objects, relationships, actions, queries, and permissions. Application interfaces, workflows, automation, and AI features can then work with the same model instead of maintaining unrelated representations of the same business concepts.
The current Sixb repository and quickstart require Bun 1.4.2 or later. The baseline quickstart does not require database configuration or API keys before the first start. That is a useful property for evaluation, but it applies only to the initial generated project. Connecting external systems, configuring providers, or adopting a persistent deployment architecture can introduce credentials, databases, migrations, and additional operational requirements.
Running bun run dev starts the development environment generated for that project. Sixb identifies three browser-facing destinations in its project materials: the application, Atlas, and API documentation. Their roles are different, and a successful response from one service does not prove that every service started correctly.
The exact host, port, and path must come from the current generated project's startup output and instructions. Sixb is under active development, so this article does not hardcode endpoint destinations that may differ between scaffold versions. After starting the project, record the complete URL shown for each interface, including any path used by the API documentation.
| Sixb interface | How to identify its address | Typical purpose | Remote exposure consideration |
|---|---|---|---|
| Application | Use the application URL reported by the generated project | Test or demonstrate the user-facing application | Normally the first endpoint to consider for a limited preview |
| Atlas | Use the Atlas URL reported by the project | Explore the model, data, and execution activity | May reveal model or operational information that ordinary users do not need |
| API documentation | Use the complete API documentation URL, including its path | Inspect and test the generated HTTP API | Can reveal routes and request shapes, and may permit interactive operations |
The procedure starts Sixb with bun run dev. It is intended for local development and evaluation, not as proof of a production-ready deployment. Sixb documents separate CLI operations for building a deployment and starting a production API, but production still requires application-specific decisions about authentication, storage, secrets, process supervision, backups, migrations, monitoring, and recovery.
Install the prerequisites
You need Bun 1.4.2 or later, a terminal, permission to create files in the project directory, and a browser. For remote access, you also need a Localtonet account and our client on the Sixb device or another device that can reach the selected Sixb service.
Install Bun on macOS or Linux
Bun's official installer supports macOS and Linux. Run the following command in a terminal:
curl -fsSL https://bun.sh/install | bashFollow the path instructions displayed by the installer. If it adds Bun to a shell configuration file, open a new terminal or reload that configuration before checking the version. For alternative package-manager and platform-specific methods, consult the official Bun installation documentation.
Install Bun on Windows
Open PowerShell and run Bun's official Windows installer:
powershell -c "irm bun.sh/install.ps1 | iex"Open a new PowerShell or terminal session after installation so the updated command path is available.
These commands download and execute Bun's official installer. Confirm that the destination is bun.sh, use a trusted network, and follow your organization's software installation policy. If executing a remote installer is not permitted, use one of the alternative methods documented by Bun.
Confirm the Bun version
bun --version
Continue only if the result is 1.4.2 or later. If the command is not found, reopen the terminal and check whether the Bun installation directory was added to the command search path. Do not scaffold the Sixb project until this check succeeds.
Install the Localtonet client
Install our current client for the operating system that will run the tunnel. Use the client download and installation option presented by the current Localtonet application for your platform. Client packaging can change over time, so do not copy an old package filename or operating-system command from an unrelated tutorial.
- Windows: obtain the current Windows client through Localtonet, complete the installer or application setup presented for Windows, launch the client, and associate it with its device-specific authentication token.
- macOS: obtain the current macOS client through Localtonet, install the application using the supplied macOS package, launch it, and complete the device authentication step.
- Linux: select the current Linux build and installation instructions that match the available distribution and architecture, complete the installation, then start the client with its assigned device token.
Keep the Localtonet authentication token private. It identifies the client device that can run the tunnel. Do not put it in the Sixb repository, a shell script committed to source control, screenshots, issue reports, or shared terminal output.
The easiest topology is to run Sixb and our client on the same machine. If the client runs on another device, that device must be able to reach the Sixb host using a network address on which the selected service is listening. The word localhost always refers to the device on which it is used.
Prepare the project location
The quickstart below creates a directory named my-app. Choose a parent directory where your user account can create files. If a directory named my-app already exists, choose another project name or move to a different location. Do not run a scaffolding command over files you need to preserve.
A tunnel cannot repair an incomplete installation, a failed development process, or an incorrect local address. First make the selected Sixb interface work from the device running our client. Configure the tunnel only after that local test succeeds.
Create and start a Sixb project with Bun
The current Sixb quickstart uses four commands in a defined order. It scaffolds the project, enters the new directory, installs its dependencies, and starts development mode. The same sequence appears in the official Sixb setup guide.
Create the project
Run the Sixb project creator with a project name. The documented example uses my-app. If you choose another name, use the resulting directory name in the next step.
Enter the generated directory
Change the terminal's working directory to the project created by the scaffolder. Dependency, development, and project-check commands must run in the appropriate project directory.
Install dependencies
Run bun install and allow it to finish. Review any error before continuing. A partially completed installation should not be treated as a working baseline.
Start development mode
Run bun run dev. Keep the terminal open and read the startup output. The generated services remain available only while the process is running successfully.
bun create sixb my-app
cd my-app
bun install
bun run dev
The first command invokes the Sixb scaffolder and creates a project named my-app. The second enters it. bun install installs the declared dependency set, and bun run dev executes the generated development script.
Read the files and instructions generated for your installed version before changing the project. Sixb's documentation explicitly recommends using the documentation and installed package versions rather than guessing APIs. Keep the baseline intact until it starts successfully, then make one meaningful change at a time.
Do not close the development terminal after startup. If the command exits and returns control to the shell, the development services are no longer running, even if a browser still displays a previously loaded document.
Scaffolding and dependency installation create files and obtain packages required by the project. Inspect the generated files, avoid running the command in a sensitive directory, and keep secrets outside committed source. The initial quickstart does not require API keys, so an unexpected request for credentials during baseline setup should be investigated.
Discover and verify every local endpoint
Leave bun run dev running and inspect its output for the application, Atlas, and API documentation links. Also check the generated project instructions if the terminal output refers you to them. Record each complete URL exactly as presented, including its scheme, host, port, and path.
Open the application URL
Open the application address reported by the project. Confirm that it loads as an active application rather than returning a connection error or displaying only a stale cached page.
Open the Atlas URL
Open the reported Atlas address and confirm that its interface is distinct from the user-facing application. Note that Atlas can reveal model, data, and execution details.
Open the API documentation URL
Use the complete URL shown for the API documentation. Preserve any path reported by the project. A path is part of the browser request, not part of the local port field used by the tunnel.
Select one endpoint for remote access
Decide whether the remote user needs the application, Atlas, or API documentation. Record the chosen service's local IP address, port, and any browser path so the tunnel can be configured without exposing an unrelated interface.
Separate the network target from the URL path. For example, if a generated URL has the structure http://localhost:PORT/some-path, the Localtonet target uses the local IP address and PORT. The remote browser then requests /some-path through the assigned public URL. Do not enter a path into a port field.
Use this local verification checklist
bun run devremains active and is not repeatedly restarting with errors.- The browser uses the exact address reported for the intended interface.
- Any API documentation path is included.
- A fresh request succeeds without a connection-refused or unreachable message.
- The displayed interface belongs to Sixb rather than another process using the same port.
- The endpoint works from the device that will run the Localtonet client.
- The selected interface is appropriate for the intended remote audience.
In a browser on the Sixb computer, localhost points back to that computer. On a phone or another workstation, it points to that other device. Localtonet makes the selected service remotely reachable by forwarding a public endpoint through our connected client to the configured local IP address and port.
Operate the project and upgrade it carefully
For routine development, enter the generated project directory and run bun run dev. Keep the process attached to a terminal where you can inspect its output. Stop it using the normal interrupt mechanism for your terminal when work is complete.
Sixb and Localtonet have independent lifecycles. A configured Localtonet tunnel does not start the Sixb service, and creating a tunnel does not mean the tunnel is running. Remote access requires all of these conditions at the same time:
- The Sixb development process is running successfully.
- The selected interface is reachable from the Localtonet client device.
- The Localtonet client is connected with the intended device token.
- The tunnel points to the correct local IP address and port.
- The tunnel has been started.
- The remote browser uses the correct path, if the selected interface requires one.
Follow the installed project's instructions
Use the package versions installed for the project and read version-matched instructions before adopting examples. Sixb is in active development, and APIs or generated structures can change. An example written for another release may not match the packages in your project.
Review every 0.1.x upgrade
Sixb warns that releases in the 0.1.x line can include breaking changes and database migrations. Review the repository's Sixb changelog and the release notes for the exact version before changing dependencies.
The Sixb 0.1.15 release notes, for example, require coordinated upgrades across core packages and runtime consumers, Atlas 0.1.13, and the Microsoft connector where applicable. They also require rebuilt application assets and PostgreSQL or SQLite migrations 051 through 052 with old runtime roles stopped.
Those release notes recommend rehearsing the migration against a representative 0.1.14 database backup, measuring downtime and storage requirements, and verifying projections afterward. They also state that rollback requires a database backup and matching binaries, not merely an older application commit.
If a release includes data or schema migrations, prepare and test a data recovery plan before upgrading. Apply release-specific instructions only to the versions and storage systems they cover. Do not blindly run migration steps from an unrelated release.
Keep development and production responsibilities separate
Sixb documents CLI operations such as bun sixb build and bun sixb api, but a production command does not provide every surrounding control needed for a dependable public deployment. Production planning still includes authentication, least-privilege permissions, persistent storage, secret management, migrations, process supervision, logging, monitoring, backup, and recovery.
This tutorial intentionally remains within a narrower scope: it creates the documented Bun development environment and adds temporary remote access to one selected service. Do not present bun run dev as a production deployment.
Configure a Localtonet HTTP tunnel for one Sixb endpoint
Once the selected Sixb interface works locally, configure an HTTP tunnel that forwards to its local IP address and port. Use the current Localtonet HTTP tunnel documentation alongside the sequence below when checking the current dashboard.
Before beginning, separate the chosen URL into three values:
- Local IP address: the address through which our client can reach Sixb. If both run on the same device, use the locally reachable address reported or supported by the generated project.
- Local port: the numeric port in the chosen Sixb URL.
- Browser path: any part after the host and port, such as the path reported for API documentation. You will request this path through the public URL after the tunnel starts.
Install and run the Localtonet client
Run our client on the Sixb device or another device that has already reached the selected Sixb URL successfully. Confirm that the intended device is connected before configuring its tunnel.
Open the HTTP Tunnel page
In the Localtonet dashboard, go to the HTTP Tunnel page. Use HTTP tunneling because the selected Sixb interface is a browser-accessible HTTP service.
Select the Process Type
Choose the available Process Type appropriate for the public address: Random Sub Domain, Custom Sub Domain, or Custom Domain. These process types serve the configured content at a public HTTPS address. Availability can vary, so use the options shown in the current dashboard.
Select the AuthToken and server
Select the device-specific AuthToken for the client that can reach Sixb, then choose an available server from the current dashboard. Do not copy a token or server code from an example.
Enter the local IP address and port
Enter the IP address and port recorded during local verification. The target must identify the chosen Sixb service as reached from the selected client device. Do not place a URL path in the port value.
Press Start
Press Start to run the tunnel. Creating or saving a tunnel does not mean it is active. Keep the Sixb process and Localtonet client running while remote access is required.
After the tunnel starts, use the public HTTPS address assigned by the dashboard. If the selected Sixb interface has a path, append that same path to the public address. Test from a separate browser session or remote device so the request follows the public route.
| Remote-access goal | Local target | Public request | Recommended scope |
|---|---|---|---|
| Share the generated application | Application IP address and port reported by the project | Assigned public URL plus any application path | Create one HTTP tunnel for the application |
| Inspect Atlas remotely | Atlas IP address and port reported by the project | Assigned public URL plus any reported Atlas path | Expose only when remote Atlas access is necessary and protected |
| Open API documentation remotely | API service IP address and port reported by the project | Assigned public URL plus the documented API documentation path | Restrict access because the interface can reveal or exercise API capabilities |
One HTTP tunnel points to one local IP address and port. It does not automatically publish every Sixb service. If multiple interfaces genuinely require remote access, create and review separate configurations for them rather than broadening the first tunnel without considering the exposure.
Stop the tunnel when remote testing is finished. Delete it if the configuration is no longer needed. A tunnel is available only while the selected client is connected and the tunnel is running.
A service that was previously reachable only on the development machine becomes reachable through the assigned public endpoint. Localtonet provides connectivity, but it does not replace authentication, authorization, or permissions inside Sixb. Confirm that the chosen interface and data are appropriate for the intended audience before starting the tunnel.
Protect a remotely accessible Sixb development service
Treat remote access to a development process as deliberate and temporary. A collaborator reviewing the application does not normally need Atlas or interactive API documentation. Selecting one endpoint reduces the exposed surface and makes the access decision easier to review.
0.1.x releases can contain breaking changes and migrations.
Be cautious with Atlas
Atlas is designed to explore the model, inspect data, and follow work through the system. Those capabilities are useful to developers and operators, but they can reveal information that a normal application user does not need. Do not assume that an application approved for a remote demonstration makes Atlas appropriate for the same audience.
Treat interactive API documentation as an operational interface
API documentation can describe routes, request structures, response formats, and operations. Depending on the generated interface and project configuration, it may also allow interactive requests. Verify authentication and permissions before exposing it. If the remote task only requires the application, keep the documentation service local.
Keep every credential outside the repository
The initial quickstart requires no API keys. Later integrations may add provider tokens, OAuth settings, database credentials, or other secrets. Use the project's documented secret-handling approach and never commit live credentials. A Localtonet device token belongs to the client configuration and is not Sixb application source.
This workflow exposes one selected HTTP service through a public HTTPS address. It does not join a remote device to the local network. Localtonet VPN Manager is the separate feature intended for private mesh VPN use cases.
Troubleshoot installation, startup, and remote access
Troubleshoot in layers: Bun, project generation, dependency installation, the Sixb development process, the local endpoint, the Localtonet client, and finally the public tunnel. Find the first failing layer before changing later ones.
bun is not recognized
Open a new terminal and run bun --version. If the command still cannot be found, check the installation output for the directory that must be added to the command search path. Repeat the installation only after understanding the original error. Confirm version 1.4.2 or later before retrying Sixb.
The project creation command fails
Confirm that the command follows the documented structure:
bun create sixb my-appVerify that the current directory is writable and that an existing directory with the same project name is not causing a conflict. Preserve and read the complete error output instead of repeatedly running the command.
bun install reports an error
Confirm that the terminal is inside the generated project directory. Check the Bun version and review the first meaningful dependency or network error. Do not proceed to bun run dev until installation completes successfully.
bun run dev cannot find the script
This usually means the command is being run outside the generated project or scaffolding did not complete. Confirm the current directory and inspect the generated package scripts and instructions. Do not add a guessed script merely to suppress the error.
The project starts but an interface does not load
Keep the development terminal visible and use the exact URL reported for that interface. Check the scheme, port, and path. A successful application page does not prove that Atlas or API documentation started. Look for startup errors or a port already occupied by another process.
If a port conflict is reported, identify the conflicting process and stop it only when safe. The current evidence for this guide does not establish a universal Sixb flag for remapping generated service ports, so no speculative option is provided. Follow the generated project's version-specific instructions if it supports changing them.
A browser shows an old page after Sixb stopped
A cached document is not proof that the service can answer a new request. Open a new tab or perform a fresh reload while observing the development terminal. Confirm that the process remains active and handles the request.
The Localtonet tunnel is configured but unreachable
Confirm that the tunnel was started with the Start button. Verify that the selected client is connected with the intended AuthToken and that Sixb remains running. Then compare the tunnel's local IP address and port with the locally verified endpoint.
The public URL opens the wrong Sixb interface
The tunnel is probably targeting the address or port of another service. Compare the configuration with the URLs printed by the current project, correct the tunnel configuration through the current dashboard workflow, start it as required, and test again. Do not rely on port numbers copied from an older scaffold.
The public API documentation URL returns a not-found response
Check whether the generated API documentation URL includes a path. If it does, append the same path to the Localtonet public hostname. The tunnel selects the local service by IP address and port, while the browser path still selects the documentation route.
The client and Sixb run on different devices
Do not use the Localtonet client's own localhost unless Sixb runs on that same device. Enter a local network address through which the client can reach the Sixb host. Test that address from the client device first. If Sixb listens only on the host's loopback interface, another device cannot reach it without a supported bind-address configuration. Consult the generated Sixb instructions rather than guessing a flag.
The public endpoint worked and then stopped
Check both lifecycles. Sixb must still be running, and the selected Localtonet client and tunnel must remain connected and active. Closing the development terminal, stopping the tunnel, disconnecting the device, restarting the host, or losing outbound connectivity can interrupt access.
An upgrade causes project or data problems
Stop and review the release notes for the exact versions involved. Sixb warns that 0.1.x releases can include breaking changes and migrations. Reverting source code does not necessarily restore migrated data. Use the backup, migration, and rollback plan prepared for that deployment.
If the local URL fails from the client device, fix Sixb or local reachability before changing the tunnel. If the local URL works but the public URL fails, inspect the selected AuthToken, client connection, local IP address, port, server selection, path, and tunnel running state.
Frequently asked questions
Which Bun version does the Sixb quickstart require?
The current Sixb quickstart requires Bun 1.4.2 or later. Check the installed version with bun --version before creating the project.
Does the initial Sixb quickstart require a database or API key?
No database setup or API keys are required for the documented initial quickstart. A project can add those requirements later when it connects external systems, configures providers, or adopts persistent storage.
What commands create and start a Sixb project?
Run bun create sixb my-app, enter the project with cd my-app, install dependencies with bun install, and start development mode with bun run dev.
Which local ports does Sixb use?
Use the ports and complete URLs reported by the current generated project. Sixb is under active development, so this guide does not hardcode port or path values that may differ between scaffold versions.
Can one Localtonet HTTP tunnel expose every Sixb interface?
A standard HTTP tunnel points to one local IP address and port. It does not automatically expose services listening on other ports. Configure separate tunnels only when multiple interfaces genuinely require remote access.
How do I expose a Sixb URL that includes a path?
Configure the tunnel with the service's local IP address and port. After Localtonet assigns the public URL, append the same path shown by Sixb. A path is part of the browser request and is not entered as a port.
Does Localtonet require router port forwarding?
No. Our client establishes an outbound connection to a Localtonet relay server. This workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Does the public endpoint remain available when Bun or the client stops?
No. The selected Sixb service must be running, the Localtonet client must remain connected, and the tunnel must be started. If any of those conditions stops, the public endpoint cannot continue serving the selected local interface normally.
Is bun run dev a production deployment?
No. It starts the documented development environment. Production requires application-specific planning for storage, authentication, permissions, secrets, process supervision, migrations, backups, monitoring, and recovery.
What should I review before upgrading a Sixb 0.1.x project?
Review the changelog and exact release notes because 0.1.x releases can contain breaking changes and database migrations. Identify coordinated package versions, back up applicable data, understand migration and downtime requirements, and prepare a rollback process that covers data and matching binaries as well as source code.
Make a verified Sixb endpoint available with Localtonet
Start Sixb locally, confirm the exact application, Atlas, or API documentation URL reported by your project, and create a focused HTTP tunnel for only that service. Keep remote access active for the required workflow, then stop or delete the tunnel when the task is complete.
Get Started Free →
