termynl documentation

Keyboard-first project management. Teams · tasks · issues · projects · views · docs · agents on one object model. Updated for version 0.25.1.

What is termynl

termynl is a project-management workspace built for people who live on the keyboard. Teams, tasks, issues, projects, saved views and docs all sit on one object model and one change bus, so backlinks, activity, notifications, real-time updates and AI actions are built once and work everywhere. An agent that moves a task leaves the same activity a person would.

Getting started

1. Sign in with Google, Microsoft (work or school) or GitHub (the buttons at the top of the sign-in page), or with an email link below them. Use the address you were invited with, or one on a domain your workspace has verified. If you have neither an invite nor an address on a verified domain, you'll see a "no workspace" screen: ask an admin for access.
2. Find your teams. The left sidebar lists your teams under TEAMS. Open the team directory to join an open team.
3. Create a task: press ^K c t. It lands in the team you're looking at and opens straight away so you can fill in the details.
4. Pick a layout: on a team's Tasks page, ^K v b switches to the board and ^K v l back to the list.

Keyboard

Every termynl shortcut is the same shape: press Ctrl+K (⌘K on a Mac), then one or two letters. It's identical in every browser and on every OS. Below, ^K means that prefix. You can change the prefix letter in Settings → Keyboard, and ^K ? shows the full list.

Standard keys

Mod is Ctrl on Windows and Linux, ⌘ on a Mac.

Teams

A team owns its projects, tasks, issues and views. People can belong to many teams.

• Sidebar tree. Under TEAMS, each team opens to Projects, Tasks (with its open count), Issues and Views. That tree is how you move around a team on a computer; on a phone, the bottom bar switches team and page, and the prompt bar opens the command palette. ^K g 1–9 jumps to a team.
• Team key. Every team has a short key, like PROD, which prefixes its item numbers. If you rename the key, the old key keeps working in links.
• Directory. The team directory lists the teams you can see and lets you join an open team. Any member can create a team with ＋ New team.
• Visibility. Private: members only. Open: every workspace member (not guests) can find, read and join it; its members write. Everyone: every workspace member (not guests) can read and write. Only workspace owners and admins can make a team visible to everyone.
• Team settings (Settings → Teams, then the team): name, key, icon, color, visibility, and members and admins. Team admins and workspace admins can change them. A team always keeps at least one admin.

SCIM groups → teams

• Link one group. In Team settings → SCIM group, a workspace admin links a team to one SCIM group from your identity provider. Team admins can see which group is linked and its member count, but only a workspace admin can change the link.
• Members follow the group. People are added to and removed from the team automatically as the group's membership changes in your identity provider.
• Hand-added people are never touched. Someone added to the team directly stays, even after a group link.
• Guests are never added by a SCIM group.
• Leaving the group removes them from the team. To keep someone past that, promote them to team admin first. That makes their membership permanent.

Tasks & issues

Tasks are work to do. Issues are problems to track, with a reporter and the affected area. Both live in a team (or in your personal space) and share the team's numbering.

• Keys and permalinks. Every item shows a key like PROD-12. Its permanent link is /items/PROD-12. Focus a row and press Mod+C to copy a ready-made markdown link.
• Multiple assignees. Assign as many people as the work needs.
• Priorities: None, Low, Medium, High, Urgent.
• Where new items land. In the team or project you're looking at. Outside any team, an item goes to your personal space, assigned to you.
• Move (^K m, or ⇄ Move on an item) to any team you can write to, or to Personal. The item gets a new key in its new team, and the old key still resolves, so existing links don't break.
• Issues have their own page on every team (^K g i), with the same List, Board, Table and Timeline views and saved views as tasks. ^K c i files a new issue and opens it.
• Reporter and affected. An issue records who reported it (a member of the workspace) and what it affects, such as a component and version.
• Linked tasks. Link the tasks that fix an issue: each shows its live status, and the issue counts how many are done. You can only link items you can see, and a linked item stays hidden from anyone who can't already see it.
• Source. Issues filed in termynl are marked local.
• Convert. ⇆ Convert turns a task into an issue, or an issue back into a task. It stays the same item: same key, links, comments, files and history. An issue turned into a task drops its reporter, affected area and linked tasks (you're asked first). Guests can file issues, but can't convert or move them.

Projects

A project groups a team's tasks toward an outcome. Each project has a status, priority, assignees, start and target dates, labels and a color.

The six project statuses: Backlog · Planned · In progress · Paused · Completed · Canceled.

The project page shows its details, its progress, and its tasks. Moving a project to another team takes all of its tasks with it.

Views

A team's Tasks, Issues and Projects pages are views: a layout plus filters, grouping, sorting and the fields to show.

• Layouts: List, Board, Table and Timeline (^K v then l / b / t / r). A view remembers its layout.
• Filter builder (^K f). Filter by status, priority, assignees, labels, project, creator, title and dates. Active filters show as chips.
• Group and sub-group by status, priority, assignees, labels or project.
• Sort by several fields at once.
• Display fields. Choose which fields show on each row or card.
• Board drag. Dragging a card to another column changes its status, priority or assignee to match that column.
• Table. One column per display field, with the header pinned while you scroll. Click a column to sort by it; click again to reverse, and a third time to clear. Edit status, priority, assignees, labels and dates right in the cell: arrow keys move between cells, Enter edits, Esc cancels.
• Timeline. Each task or issue is a bar from its start date to its due date; each project runs from its start date to its target date. Drag a bar to move it, or drag either end to change one date. On the keyboard, press Enter on a bar to type the dates. Zoom by week, month or quarter. The amber line is today. Items without dates wait in Unscheduled.
• Open an item and it shows beside the list; the view tabs and the filter row fold away to give the list and the item the room. Close the item to get them back. ^K f closes the item and opens the filter builder.
• On a phone a table shows as a list, and a timeline as an agenda by month.

Saved views

• Views appear as tabs. Save the current setup with ^K c v or ＋ view. Your own views save as you change them.
• Personal views are yours alone. Share one and your team sees it as "shared by you". Only you can edit it.
• The ★ team default is the view everyone lands on. Team admins choose it.
• A team's Views page lists every view you can see.

Docs & the editor

Docs, task and issue descriptions, and comments all use the same block editor. Text in the editor is a little smaller than before, so more of a doc fits on screen.

• Slash menu. Type / to insert a block. The menu has five sections: Text (text, headings 1–3, quote), Lists (bulleted, numbered, to-do and toggle lists), Blocks (callout, toggle headings, table, 2 or 3 columns, divider, code block), Media (emoji) and Advanced (footnote, mention a person, link a task or doc). Keep typing to filter the menu.
• @ links. Type @ to mention a person or link a task, issue or doc. Links are real connections, not text: both ends show them.
• Callouts. A highlighted box for a note, tip, warning and more (note, summary, info, to do, tip, success, question, warning, failure, danger, bug, example, quote). Pick the type and edit the title on the callout itself. Turn on folding to let readers collapse it, and choose whether it starts open or closed.
• Highlights. Select text and press Mod+Shift+H, or type ==text==.
• Footnotes. Insert one from the slash menu (Footnote). It becomes a numbered reference, and the note text collects at the bottom of the doc.
• Toggles. A toggle list hides its content behind a title you click to open or close. A toggle heading does the same under a heading 1, 2 or 3.
• Columns. Lay a doc out in 2 or 3 columns side by side. Any block can go in a column. A thin divider line separates the columns; Hide divider in the block menu turns it off (and Show divider brings it back). Unwrap columns in the block menu puts the content back in one column.
• Tables. Real tables with a header row. A table menu gives you Row above, Row below, Column left, Column right, Delete row, Delete column, Header row and Delete table.
• Code highlighting. Type three backticks and a language, such as ```ts, to start a code block that is colored for that language. In the slash menu, add the language after Code (for example /code python).
• Block handle. Each block has a handle. Drag it to move the block, or open its menu: Duplicate, Move up, Move down, Insert line above, Turn into (text, headings, lists, quote, callout, toggle list, code block) and Delete. From the keyboard: ^K o opens the menu, Mod+Shift+↑ and Mod+Shift+↓ move the block, and Mod+Shift+D duplicates it.
• Emoji. Type : and a few letters to pick from a list, or write a whole :shortcode: such as :rocket:. Emoji is also in the slash menu.
• Links to a heading or a block. Type [[ to open a picker and link a doc, one of its headings, or a single block. In text these read [[Title]], [[Title#Heading]] and [[Title#^block]]. Add a label with [[Title|label]] to show your own words instead of the title. Links keep working when the target doc is renamed. Copy link to block in the block menu copies a link to the block you're in.
• Embeds and synced blocks. Show another doc, one of its sections or a single block inside this one: ![[Title]], ![[Title#Heading]] or ![[Title#^block]]. An embed is a read-only view that stays in step with the original; click Open source to edit the original. You only see an embed of a doc you can open.
• Tags. Type #tag in text and it shows as a chip. Click a tag to search for it.
• Page icons and covers. Give a doc an emoji icon and a cover: one of the gradients, or an image you upload.
• Images, files and video. Paste or drop an image into a doc and add a caption under it. Other files show as a card you can download. Videos play in the page (skipping ahead or back isn't supported yet).
• Link previews. Turn a link into a card with its title, site name and image. The server fetches the preview once, when you add it.
• Web embeds. Embed a live view from YouTube (in privacy mode), Vimeo, Loom, Figma, Google Docs, Google Sheets, Google Slides, Google Maps, Miro or CodePen. A link to any other site becomes a link preview instead.
• Editing at the same time. An open doc picks up changes someone else saves while you are not typing. If they save first while you have unsaved text, your text stays and a notice offers Load latest (show their version) or Keep mine (save yours over it). If a save fails, your text is kept and the doc offers Retry or Discard; the browser asks before you close a tab that still holds unsaved text.
• Leaving a block. Mod+Enter exits the block you're in and continues on a new line below.

Markdown

Every block has a Markdown form, so you can paste Markdown in, export it, and edit docs in other Markdown tools such as Obsidian. Properties at the top of a note (YAML frontmatter between --- lines) come in on import and go out on export: the title, aliases, tags, icon, cover and your shared properties by name. Blocks that plain Markdown has no syntax for are written in a form other tools show sensibly (for example a toggle appears as a collapsible section, and columns appear stacked).

Things that don't survive a round trip are small: for example column alignment in tables, link titles, and which toggle was open in a closed copy; formatting in a caption; YAML comments and key order in properties; and a link preview's description, site name and image (only the title is kept). Other Markdown tools show a web embed or a link preview as a plain link.

Links & the graph

@-mentions are structured links, never text matching. Each one creates a two-way connection, so every task, issue and doc shows what links to it and what it links to. The connections page draws the live graph of those links.

• It follows what you opened last. Connections centres on the item you looked at most recently. Use the picker to re-centre it on any other item.
• Always current. Links added anywhere else appear in the graph live, without a refresh.

Shared properties

Add your own fields to items. A property can be defined for the whole workspace (workspace admins), for a team (team and workspace admins) or for a project (people who can edit the project). Each property picks which item types it applies to: tasks, issues, projects and docs. Every item of those types in that scope then has the field.

Members & guests

• Roles: owner, admin, member and guest. Owners and admins manage members in Settings → Workspace → Members and seats: change roles, deactivate, reactivate or remove people, and transfer ownership.
• Invites. Admins invite people by email and pick their role.
• Names. People show by their display name. Someone who hasn't set one shows by their email to other members. Guests don't see other people's emails.
• Guests are walled off. A guest sees only the teams and projects explicitly shared with them. They never see the team directory or anything else in the workspace. People on your own verified domain can't be guests.
• Seats. On the hosted service, every member takes a paid seat. Guests are free, up to five per paid seat.

Let members share with guests

A workspace admin can turn on Members can share with guests in Settings → Workspace → Members and seats → Sharing (off by default). With it on, anyone who can edit a task, issue or project can share it with an existing guest, and remove a guest from it. Inviting someone new, revoking invites and Stop sharing stay with team admins. MCP: set_join_policy {membersShareGuests: true}.

Share one task or issue

Share on the header of every task and issue (👥 People on a project) does the sharing. Type a name or email:

• A workspace member gets assigned.
• An existing guest shows as "Share with <name> (guest)".
• An email nobody recognizes shows as "Invite & share as guest" (below).
• What the guest sees. Only that item: its subtasks, comments, files and activity. Never its project or team, and never who else is on it.
• Keys stay the same while an item is shared.
• Who has access. The same 👥 People popover lists who already has access (the team, assignees, guests and pending invites), with Unassign, Remove or Revoke, plus Stop sharing.
• While shared, the item can't be moved to another team or deleted, and its project or parent can't leave the team. Stop sharing first. Stop sharing returns it, with its subtasks, comments and files, under its parent task or project wherever that lives now (otherwise to its team).
• Shared items show up for the guest under Shared with you.
• Who can do what. Team admins and workspace admins can always invite a new guest, revoke an invite and Stop sharing. When a workspace admin turns on Members can share with guests, any member who can edit the item can also share it with an existing guest, or remove one. This is off by default, so until then other members see the same 👥 People control but can only assign teammates.

Invite & share as guest

Type an email that isn't in the workspace into Share (👥 People on a project), and it becomes a guest invite scoped to that one task, issue or project. Nothing else is granted. It's pending until accepted (one pending share invite per address at a time), and team admins can send it. Addresses on your workspace's verified domains can't be shared with as guests: a workspace admin invites them as members. A workspace admin can also invite guests straight into a team from Settings → Workspace → Members and seats, or ^K Invite people.

What guests see

• No other people. A guest never sees assignees, reporters, member lists or names besides their own; other people's comments show as "Team".
• No team keys, no emails. Only what's shared with them, listed under Shared with you.
• A number, never a key. A guest sees a task's or issue's number (#46), never its team key; numbers count per team, so a guest can tell roughly how many items that team has numbered.
• File links end with sharing. A guest's links to files stop working when sharing ends. A link already opened can stay valid for up to 5 minutes after access is removed.
• 👥 People and the ^K "People on this item" command are offered to every member, never to a guest.

Share a project

Team admins and workspace admins share a project the same way, through 👥 People on its header.

• What the guest sees. Only that project: its tasks, issues, comments and files. Never the rest of the team, and no team keys.
• Keys stay the same. A shared project's tasks keep their existing keys.
• Stop sharing returns the project to its team. Removing the last guest does the same.
• While shared, a project can't be moved to another team or deleted. Stop sharing first.
• Moving an item out of a shared project, to its team or another team, removes it from the guests' view.

Invite people into teams

• An invite (Settings → Workspace → Members and seats → Invite, or ^K Invite people) lets an admin pick which teams the person joins as soon as they accept.
• A guest invited with teams picked joins those teams as a guest.
• An everyone-team needs no invite: every workspace member is already in it.

Account ids

Account ids are random, never derived from your email address. Existing workspaces move to the new ids in a short maintenance window; afterwards everyone signs in again once. Links, keys like PROD-12, shares and history are unaffected.

Sign-in & identity

• Profile and sign-in. Edit your profile in Settings → Profile. In Settings → Sign-in and sessions, link several sign-in methods (Google, Microsoft, GitHub, email) to one account, and see and end your sessions.
• Verified domains and auto-join. An admin proves the workspace owns a domain (with a DNS TXT record). Anyone who signs in with a verified address on that domain then joins as a member.
• Group gate. Limit who may join to members of chosen Google Workspace or Microsoft Entra groups. Membership is re-checked on a schedule. Someone who leaves the group is deactivated after a grace period, and a provider outage never deactivates anyone.
• SCIM 2.0 provisioning from your identity provider (Entra natively).

These join rules can be combined, and admins set them in Members → Join policy.

Deleting your account

• In Settings → Profile → Delete account (or the request_account_deletion MCP tool) we email you a confirmation link. Once you confirm it while signed in, your account is scheduled for deletion 30 days later and your other sessions are signed out. You can cancel any time before then. This works even while a workspace you're in is locked after its subscription ended: the locked screen has a Delete my account button.
• After the 30 days your account is deleted automatically: sign-in methods, profile and picture, preferences, sessions and connected apps.
• Your items are kept. In each workspace, your personal items, the items assigned to you and the items you created go to the member an admin picked in Settings → Workspace → Data and export (by default the workspace owner). Content in shared spaces stays with the workspace. History (who did what) isn't rewritten.
• Your synced email, calendar and contacts, and everything attached to them (shared mailboxes included), are deleted, never handed over. Files you kept in your own Google Drive or OneDrive stop opening in termynl once your account is deleted; admins see how many there are.
• If you're the only owner of a workspace with other members, transfer ownership first. A deletion can be paused while a legal obligation requires the data to be kept (a legal hold); it can't be cancelled while it's on hold.

Notifications & email

Everything that happens to items you're on shows in your inbox in the app. Each kind of notification can also email you:

• Your choice: Settings → Profile → Email notifications: turn each type on or off, pause all notification email that isn't locked by an admin, or get a daily summary instead of one email per item.
• Your workspace admin's defaults: Settings → Workspace → Email delivery: the default for each type, and whether members may change it ("locked").
• Your team admin's defaults: a team's settings → Notifications: the same for the team's items (assigned, changes, mentions). Without a lock, the most specific setting wins: your own choice, then the team's default, then the workspace's. A lock beats personal choices: a workspace lock always wins, then a team lock.
• Private to you. Your inbox is yours alone: no other member ever sees your notifications.
• Comments on docs: a new comment on a doc notifies the doc's author and its followers, and the doc shows 1 new.
• Comments: a new comment on a task or issue notifies its assignees and followers who can see it (never the author; someone the comment @-mentions gets the mention instead). By email it counts as Changes to your items.
• @-mentions: type @ and a teammate's name in a description, a doc or a comment; they get a notification (and an email, unless it's turned off for them). Mentioning the same person again in the same text doesn't notify them twice.
• A burst of edits to one item becomes one email, sent once the item has been quiet for 2 minutes (at most 10 minutes after the first change).
• Emails carry the item's key and title ([PROD-12] Fix login), who changed it and a link, never its description or comments. Guests see #12 and no names.
• Sign-in links, invitations and security notices are always sent.
• Admins can send a test message to themselves and see the workspace's recent deliveries (delivered, bounced, marked as spam) in Settings → Workspace → Email delivery. Addresses that bounce permanently or mark mail as spam stop getting notification email.

Storage

On the hosted service, a workspace admin chooses where file attachments are stored: Google Drive, OneDrive, or an S3-compatible bucket. Your file bytes live in your own cloud. termynl keeps only what it needs to find and link them.

• Test the connection before switching. When you change backends, termynl migrates existing files and verifies each copy.
• Attachments up to 100 MB, shown in the Files card beside each item.
• Local storage (files on the server's own disk) is available only when you self-host.

Workspace settings

• Settings → Modules lists Issues next to Tasks. Issues can be switched off while Tasks stay on.
• Settings → About sets the workspace name (admins). It shows in the brand row at the top of the navigation.

Tyn, the assistant

Tyn is termynl's built-in assistant. It works through the same pipeline you do, with your permissions and never more. Whatever it changes shows up in activity as "via Tyn".

Ask Tyn about an item. Choose Ask Tyn from an item's ⋯ menu, from a doc's or a project's ⋯ menu, or press ^K t. Tyn starts with the item's key, title and id, so you don't have to explain which one you mean.

MCP & connected apps

Any MCP client, such as Claude Code or claude.ai, can connect to termynl at https://api.termynl.com/mcp. Everything you can do in the app has an MCP tool.

What Tyn and Claude can do

Tyn and Claude over MCP can do what you can do in termynl, as you, with your permissions and never more. The main areas:

• Items: create, read, update, move and convert tasks, issues and projects; create and edit docs and daily notes; create from a template; comment; link and unlink items; follow and unfollow; read an item's history and restore an earlier version.
• Properties: list, create, change and delete shared properties, and check how many items use one.
• Views: list, create, change, delete and run saved views.
• Files: list, attach, delete and get a 5-minute download link for attachments.
• Inbox: list your notifications and mark them read.
• Teams and people: list teams and people, join or leave a team, and (admins) manage members, roles, invites and guest sharing.
• You: your profile, preferences, sign-in methods, sessions, connected apps and storage choice.
• Workspace (admins): modules, workspace name, join policy, domains, directory and SCIM, email settings, storage, exports and Tyn's models.
• Billing: read-only. Tyn and Claude can show your plan, seats, renewal date, invoices, and the card's brand and last 4 digits.

Safety rules.

• Tyn deletes, restores, disconnects apps, signs out sessions or changes seats only when you ask for that in your own message, naming the item.
• Tyn never adds a card or pays. Billing pages open for you to use yourself.
• Seat changes and account deletion end with a link or a code that you confirm yourself.

• OAuth 2.1 sign-in. When a client connects, you approve it on a consent screen. Nothing is granted until you confirm.
• Scopes: termynl:read, termynl:write, and termynl:admin (offered only to admins, and requested separately when needed). An app acts as you, within the scopes you granted.
• Revoke any app from Account → Connected apps. It loses access on its next request.
• Attribution. Changes made over MCP read, for example, "Ada via Claude Code" in activity. Apps that registered themselves are marked "unverified app".
• Views over MCP. run_view runs a saved or ad-hoc view with the same engine as the app. Timeline runs return each item's start and end dates; table runs return the view's columns.
• Issues over MCP. create_issue, update_item and get_item cover reporters, affected areas and linked tasks (only the ones you can see). convert_item turns a task into an issue or back, keeping its key.
• Sharing over MCP is for team and workspace admins calling the API directly: share_item and share_project invite an email that isn't in the workspace yet; neither tool is offered to a guest or to Tyn, the in-app assistant.
• Markdown over MCP. The note and item tools accept format: "markdown": create_note, update_note and update_item take Markdown, and get_item can return a body as Markdown. The server checks every body and refuses an invalid one with a reason, so a bad body is never saved.
• Links and embeds in Markdown. [[Title]] links and ![[Title]] embeds written over MCP resolve only to docs you can read; anything else stays text. Uploaded images, files and videos of the same note keep their place when a body goes out as Markdown and comes back.

claude mcp add --transport http termynl https://api.termynl.com/mcp

Models

Admins pick which models Tyn can use.

Metered usage is shown to admins as a percentage of the workspace allowance. Bring-your-own-key models run only on your own Anthropic or OpenAI key, which you add in Settings → Workspace → AI and models.

Each seat includes a monthly AI budget. Metered usage counts against it at the model provider's list price plus 20%. Bring-your-own-key usage is billed by your provider, not by termynl. Buying extra usage beyond the allowance is coming.

Import from Obsidian or Notion

Bring an existing knowledge base in as docs, with links turned into live backlinks. Import currently runs through the API; an import button in the app is coming.

• Obsidian: [[wikilinks]] and [[link|alias]] become links (forward links work too; links outside the import stay plain text). YAML frontmatter becomes properties and #tags become tags.
• Notion: export as Markdown & CSV. Page-id suffixes are removed from titles, internal page links become backlinks, and external URLs stay links.

Workspace data

In Settings → Workspace → Data and export:

• Export (admins): the workspace's tasks, issues, projects, docs, comments, views, members and attachment files as a .tar.gz of JSON (objects.jsonl, members.json, manifest.json) and files. An owner exports the whole workspace; members' personal items stay out unless the owner ticks Include members' personal items (off by default). An admin who isn't an owner exports only the spaces they can read. One export at a time, three a day. Only the person who started an export can download it, and only while their role still allows it. Each export is kept 7 days, a workspace keeps one ready export (a newer one replaces it), and you get an email when it's ready. Files over the size limit are left out and listed in manifest.json; they stay in your storage.
• Leaving accounts (admins): when a member deletes their account, their items are kept: their personal items, assignments and the items they created go to the member you pick here (by default the workspace owner). Their synced email, calendar and contacts are deleted, never handed over. Files they kept in their own Google Drive or OneDrive stop opening once their account is deleted; you see how many there are.
• Paid seats (owners): lower or raise the number of seats yourself, never below what the workspace uses (one seat per active member, and one per five guests). A reduction is credited on your next invoice. Seats also follow membership: when an admin adds someone and no seat is free, termynl shows the seat price and adds them only after the admin confirms buying a seat (never silently; over MCP the add waits for that confirmation in the browser). Removing or deactivating someone asks whether to keep their seat or drop it. Automatic adds buy seats only within a monthly limit (10 by default): domain or group sign-ups when auto-add seats is on, and SCIM when an owner turns on Adjust paid seats automatically in Members → Join policy → SCIM provisioning (then a SCIM deactivation also drops a seat). An admin's own adds never count toward that limit.
• Delete the workspace (owners): type delete workspace to confirm. Everything is deleted automatically 30 days later, including the files termynl stores; files in your own Google Drive, OneDrive or S3 stay there. The subscription won't renew and ends when the workspace is deleted. Any owner can cancel until then; every owner and admin is emailed. A deletion on legal hold waits, and can't be cancelled while it's held.
• After cancelling: when a subscription ends, the workspace is locked. For 30 days its admins can still sign in and export its data; the locked screen also shows the date the workspace will be deleted. After day 30, export is no longer available and the locked screen shows only that date. The workspace is deleted automatically 60 days after the subscription ended; every owner and admin is emailed when it ends and on days 30, 45 and 59. Starting a paid subscription again before then cancels the deletion.

Billing

$35 per seat / month, billed on active members, after a 14-day trial. A new member's seat is added to your next invoice, prorated. Manage payment and cancel in the self-service portal. Owners change paid seats in Settings → Workspace → Data and export (see Workspace data). A self-hosted build is planned (see below).

Self-hosting

Coming soon. A single-tenant build that runs on your own infrastructure is planned, with an open-source release to follow once the license is chosen. Self-hosted, your data stays on your box by default. If you connect outside services, such as a model provider or cloud storage, they receive the data they need to work. It will deploy with Docker, with an updater sidecar to keep it current, and add two options the hosted service doesn't have:

• Local file storage on the server's disk.
• A markdown mirror of your docs. Every doc is written as a .md file on the server's disk, a one-way copy that tools like Claude Code can read. (Our hosted pilot server currently writes this mirror too; see the Privacy Policy.)

Multi-tenant orchestration and billing are part of the proprietary hosted service, not the self-host build.

Email. Set TERMYNL_MAIL_PROVIDER=smtp (with SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS) or resend (with RESEND_API_KEY), and TERMYNL_MAIL_FROM. For delivery tracking with Resend, add a webhook to https://<your host>/webhooks/resend (events: sent, delivered, delivery delayed, bounced, complained, failed) and set its signing secret as RESEND_WEBHOOK_SECRET. A provider you name without its credentials stops the server from starting. TERMYNL_NOTIFY_MAIL=off pauses all notification email.

First owner. On a fresh install, only the email set in TERMYNL_BOOTSTRAP_EMAIL can claim the first owner account. If it is unset, nobody can claim it, so set it before the first boot.

Deletions and retention jobs run daily only with TERMYNL_LEGAL_JOBS=on (the default in the compose file; unset means off); off stops them all. The operator can put a pending account or workspace deletion on legal hold.

Retention. The server trims its own logs daily (mail log 90 days, ended sessions 30 days); container logs are capped by size; database backups are yours to keep (we keep ours 1 year). Exports go to TERMYNL_EXPORT_DIR (size cap TERMYNL_EXPORT_MAX_MB, default 5120).

Known limits

• A restored task or issue gets a new number, so it has a new key.
• A signed file link stays valid for up to 5 minutes after access is removed.

Version

termynl versions read 0.MINOR.PATCH. This page describes 0.25.1 (2026-10-18). Admins can see the running version under Settings → Workspace → About.

Coming later: email, calendar, chat and calls

Email, calendar, contacts, chat and calls are turned off while termynl focuses on project management. Nobody can turn them on (not a workspace admin, the API, MCP or an agent), and their tools aren't offered. They'll return in a later release.

The data the earlier email, calendar and contacts features had stored on our hosted service was deleted on 2026-10-07. Your Google and Microsoft connections stay: they're how you sign in, store files and sync your profile, and they'll bring email, calendar and chat back when those return.

Questions? [email protected] · termynl.com