Laurence
8fd9b694f8
Persists the branding/commercial/infrastructure work (previously only in chat and on the live site) into version control. What changed: - docs/naming.md: due-diligence and the decision to brand the product Nightjar (OpenScribe domain/GitHub/trademark collisions; alternatives screened; why Nightjar). - docs/hosted-service.md: the commercial model - plan tiers (Self-host / Cloud Starter / Cloud Pro / Private), indicative pricing, backend mapping, and the build-to-sell roadmap (metering, billing, provisioning, DPA). - docs/infrastructure.md: backend infra plan. Primary option = self-host on the 3x Minisforum MS-02 cluster (one with an RTX 3050 6GB) fronted by a Cloudflare Tunnel, with node roles, the 3050 capacity reality, caveats, and a Hetzner cloud fallback. Provision-later. - site/: reproducible marketing-site source - block content for all 11 pages (rebranded to Nightjar), the navigation, the Contact Form 7 config (honeypot), the ApisCP SOAP helper (tools/apiscp.php, no secret), and a README on how the WordPress site is built and managed via the API. - state/: DECISIONS (Nightjar rebrand, hosted service, MS-02 backend), PROJECT (brand + commercial section), TODO (rename decision, trademark, mailbox, pricing, hosted-service build, infra provisioning). Why: - User asked to save everything to the repo. Captures the product rebrand, the commercialisation plan, and the infrastructure decision so a cold session has the full picture. Notes: - The repo is still named `openscribe`; the product/brand is Nightjar. A full codebase rename is deferred (tracked in TODO + docs/naming.md). - No secrets committed: the ApisCP API key is read from a local scratch file, never the repo. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
17 lines
3.9 KiB
HTML
17 lines
3.9 KiB
HTML
<!-- wp:heading {"level":1} --><h1 class="wp-block-heading">Self-host the server</h1><!-- /wp:heading --><!-- wp:paragraph {"fontSize":"large"} --><p class="has-large-font-size">The Nightjar server ingests recordings, transcribes them, writes summaries, and serves the open API. It runs happily on a home NAS, a mini-PC, or a small cloud box.</p><!-- /wp:paragraph -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">What you need</h2><!-- /wp:heading --><!-- wp:list --><ul class="wp-block-list"><!-- wp:list-item --><li>A machine running Linux (or Docker) with Python 3.11 or newer.</li><!-- /wp:list-item --><!-- wp:list-item --><li>A few GB of RAM. More if you run a large local transcription model.</li><!-- /wp:list-item --><!-- wp:list-item --><li>Somewhere to keep audio: a local disk, a NAS, or S3-compatible storage such as MinIO.</li><!-- /wp:list-item --><!-- wp:list-item --><li>Optional: a local AI runtime (Ollama) if you want everything offline.</li><!-- /wp:list-item --></ul><!-- /wp:list -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">Step 1: Get the server</h2><!-- /wp:heading --><!-- wp:paragraph --><p>Clone the repository and enter the server directory.</p><!-- /wp:paragraph --><!-- wp:code --><pre class="wp-block-code"><code>git clone <nightjar-repo>
|
|
cd nightjar/server</code></pre><!-- /wp:code --><!-- wp:paragraph --><p>The public code is being prepared for release. <a href="/contact/">Register interest</a> to be notified when the repository opens.</p><!-- /wp:paragraph -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">Step 2: Install</h2><!-- /wp:heading --><!-- wp:code --><pre class="wp-block-code"><code>python -m venv .venv
|
|
. .venv/bin/activate
|
|
pip install -r requirements.txt</code></pre><!-- /wp:code -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">Step 3: Configure</h2><!-- /wp:heading --><!-- wp:paragraph --><p>Copy the example config and edit it. Set your storage, and your AI providers (see <a href="/connect-your-ai/">Connect your AI</a>).</p><!-- /wp:paragraph --><!-- wp:code --><pre class="wp-block-code"><code>cp .env.example .env
|
|
# then edit .env:
|
|
NIGHTJAR_STORAGE_BACKEND=local # or s3 / webdav
|
|
NIGHTJAR_LOCAL_MEDIA_DIR=./media
|
|
NIGHTJAR_LLM_PROVIDER=ollama
|
|
NIGHTJAR_TRANSCRIPTION_PROVIDER=local_whisper</code></pre><!-- /wp:code -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">Step 4: Run it</h2><!-- /wp:heading --><!-- wp:code --><pre class="wp-block-code"><code>uvicorn app.main:app --host 0.0.0.0 --port 8000</code></pre><!-- /wp:code --><!-- wp:paragraph --><p>Open <code>http://your-server:8000/docs</code> to browse the live API, and <code>http://your-server:8000/health</code> to confirm which providers are wired up.</p><!-- /wp:paragraph -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">Step 5: Point the device at it</h2><!-- /wp:heading --><!-- wp:paragraph --><p>In the phone app, set the server URL to your machine, and set the device’s upload target to your storage. From then on, recordings flow in automatically: the device uploads, the server transcribes and summarises, and the results appear in the app and through the API.</p><!-- /wp:paragraph -->
|
|
<!-- wp:heading --><h2 class="wp-block-heading">Keeping it running</h2><!-- /wp:heading --><!-- wp:paragraph --><p>For anything beyond testing, run the server under a process manager (a systemd service or a Docker container) so it restarts on reboot, and put it behind a reverse proxy with HTTPS. A small always-on box is ideal; a laptop that sleeps is not.</p><!-- /wp:paragraph -->
|
|
<!-- wp:buttons --><div class="wp-block-buttons"><!-- wp:button --><div class="wp-block-button"><a class="wp-block-button__link wp-element-button" href="/build-the-device/">Next: build the device</a></div><!-- /wp:button --><!-- wp:button {"className":"is-style-outline"} --><div class="wp-block-button is-style-outline"><a class="wp-block-button__link wp-element-button" href="/hosted-plans/">Skip it, let us host</a></div><!-- /wp:button --></div><!-- /wp:buttons -->
|