# Jinear > Jinear is an open-source (AGPL-3.0), self-hostable task management and > calendar suite for indie developers and small teams. Install the whole stack > with a single Docker Compose command, no per-user pricing, and your data stays on > your own server. A hosted version is also available. This file is the full-text companion to https://jinear.co/llms.txt, which carries the product summary, pricing and site index. Below is every published blog post in full. - Install guide: https://github.com/140crafts/use-jinear/blob/main/jinear-installation-scripts/README.md - Source (GitHub): https://github.com/140crafts/use-jinear - Source (GitLab): https://gitlab.com/140crafts/use-jinear # Workflow Statuses. Add Your Own, Drag Them Into Order. URL: https://jinear.co/blog/workflow-statuses-add-your-own-drag-them-into-order/ Published: 2026-09-03 Tags: changelog, tasks Every team in Jinear has a set of statuses its tasks move through, sorted into five groups: Backlog, Not started, Started, Completed, Cancelled. Team settings has always had a screen for them. What that screen actually let you do was rename one. Adding a status, removing one, and changing the order have all worked on the server side for a long time. I wrote those endpoints and then never built the screen that uses them, so from inside the app there was no way to reach any of it. This release is the half that was missing. ## What you can do now - **Add a status.** Each group has an add field at the bottom. Type a name, and it joins that group. A team that wants "In review" between "In progress" and "Done" can have it. - **Drag them into order.** Grab a status and drop it where you want it inside its group. If dragging isn't your thing, the up and down arrows move it one step at a time. The list rearranges as soon as you let go and puts itself back if the save fails, so you always see the order you actually have. - **Rename anything.** This one worked before and still does. - **Delete what you don't use.** Jinear asks first, and tells you plainly what happens: tasks that passed through the status keep their history, the status just stops being something you can pick. Two rules stay out of your way but are worth knowing. Only team admins can change any of this, and every group has to keep at least one status. You can't empty out "Started" and leave your team with nowhere to put work in progress. ## The order follows your tasks around The order you set in settings isn't only for that screen. It's the order of the columns on your team's board, the order of the list when you change a task's status, and the order in the status filters. Put the status your team reaches for most at the top of its group and it stays at the top everywhere. ## Topics have a home now Topics are the labels you put on tasks, and until now the only way to reach them was the side menu. If you went looking for them in team settings, which is where you'd reasonably look, there was nothing. Team settings has a **Team Topics** section now, between the workflow section and the team state section, with a short explanation and two buttons: one lists the team's topics, the other creates one. Archived teams get the list button only, the same way the side menu behaves. The three topic screens picked up matching headers while I was in there. The list, create, and edit screens now open with a title and a line explaining what the screen is for, instead of a bare heading, and they line up at the same width. Small thing, but moving between settings and topics stopped feeling like moving between two apps. ## Two smaller fixes - **The new task board button is always there.** It used to appear only when you had no boards at all, which meant creating your second board sent you looking for a button that had disappeared. It sits at the top of the list now. - **One unrecognized flag no longer takes down the whole list.** For self-hosters: if your database held an instance flag this version of Jinear didn't know about, the entire flag list failed to load rather than skipping that one entry. Unknown flags are ignored now and the rest load normally. ## What's not in it yet A status belongs to the group it was created in and can't move to another one. If you add "In review" to Not started and decide it belongs in Started, you delete it and add it again on the other side. That's clumsy and I know it. The five groups themselves are fixed. They're what Jinear uses to tell waiting work from work in progress from finished work, so they're not a list you edit. Statuses also don't have their own color. Each one takes the icon and color of its group, so every status in Started looks like every other status in Started. Names carry the difference for now. --- If you self-host and something is broken, or you need something that isn't here, write to me. That's where most of this comes from. The whole thing is on [GitLab](https://gitlab.com/140crafts/use-jinear) and [GitHub](https://github.com/140crafts/use-jinear). # Instance Settings. An Admin Panel for Self-Hosters. URL: https://jinear.co/blog/instance-settings-an-admin-panel-for-self-hosters/ Published: 2026-08-27 Tags: changelog, self-hosting If you self-hosted Jinear until now, you ran it as a normal member. That was fine until you needed something a member can't do. Someone forgot their password and the instance had no mail server, so there was no reset link to send. You put Jinear on a public address and had no way to stop strangers from registering. You wanted to know which workspaces existed on your own server, and the honest answer was to open the database. There's an admin panel now, at `/admin`. It's optional, off by default, and there is exactly one admin. ## Turning it on The admin account is defined in `.env`, not in the app. The installer asks about it during setup, and writes the login to `.secrets` if you say yes. To change it later: ```bash cd ~/jinear nano .env # MANAGEMENT_ENABLED / MANAGEMENT_ADMIN_EMAIL / MANAGEMENT_ADMIN_PASSWORD docker compose up -d ``` A few things follow from doing it this way: - **`.env` is the source of truth.** On every startup, Jinear creates or promotes the account for that email and re-applies that password. To rotate the password, change it in `.env` and restart. Changing it inside the app will not survive the next restart. - **There is exactly one admin.** Any other account holding the role loses it on the next startup. Point the email at an account you already use and it gets promoted instead of a second account being created. - **Disabling revokes access.** Set `MANAGEMENT_ENABLED=false`, restart, and the role is stripped from every account. The account and its data stay. - **Keep all three keys in the file**, even when disabled. Leave the values blank rather than deleting the lines. I picked the config file over an in-app setting on purpose. If someone gets into the app, I don't want them to be one click away from making themselves an admin. Getting that role means getting shell access to the machine first. ## Updating from an older version If your instance came up before this release, the installer never asked you about an admin, so the three keys are missing everywhere. Add them yourself, in three places. Add these to the `application.properties` you mount at `/config`: ```properties jinear.management.enabled=${MANAGEMENT_ENABLED:false} jinear.management.admin.email=${MANAGEMENT_ADMIN_EMAIL:} jinear.management.admin.password=${MANAGEMENT_ADMIN_PASSWORD:} ``` Pass the variables through to the `jinear-core` service in your compose file: ```yaml MANAGEMENT_ENABLED: ${MANAGEMENT_ENABLED:-false} MANAGEMENT_ADMIN_EMAIL: ${MANAGEMENT_ADMIN_EMAIL:-} MANAGEMENT_ADMIN_PASSWORD: ${MANAGEMENT_ADMIN_PASSWORD:-} ``` Set the actual values in your `.env`: ```bash MANAGEMENT_ENABLED=true MANAGEMENT_ADMIN_EMAIL=admin@your-domain.com MANAGEMENT_ADMIN_PASSWORD=changeme ``` Restart, log in with that email and password, and the Instance Settings tab is on the right. Two things worth knowing. The password cannot contain spaces or special characters. And on every startup the account is created or promoted and its password is reset to whatever the env var says, so that variable is the source of truth. Changing the password in the app will not survive a restart. ## Instance flags The first screen in the panel is a list of switches for features that not every instance wants. Most of them exist because the answer for a company server and the answer for a five person server are different. **Authentication** - **Register with Email**, on by default. Turn it off to close registration and add people yourself. - **Forgot Password**, on by default. Needs a mail server. Turn it off if you don't have one, so nobody is left waiting for a mail that will never arrive. - **Sign in with Email Code**, on by default. Also needs a mail server. - **Sign in with Google** and **Sign in with Apple**, both off by default, because both need credentials you have to set up yourself. **Workspaces** - **Workspace Creation**, on by default. Turn it off to keep workspace creation on the instance for yourself, where people join workspaces only by you instead of starting their own. **Integrations** - **Google Calendar**, off by default, and it needs Google OAuth credentials. Calendars that are already connected keep syncing when you turn it off. A flag hides the feature in the app and the API refuses it. Turning off registration doesn't just remove the button. ## Workspaces, teams, accounts The other three screens are for the things I used to open the database for. - **Workspaces.** Everything on the instance, with its owner and tier. Create one and pick any account as owner, rename it, change its tier, add and remove members, delete it. - **Teams.** Grouped under the workspace they belong to. Create, rename, manage members, delete. - **Accounts.** Every account on the instance. Create one with an email and a password, which is the manual path when registration is closed. Set a new password for someone who lost theirs, and they're asked to change it at their next sign in. Open an account to see which workspaces and teams it belongs to. An account you create here starts with no workspace of its own, on purpose. You add it to an existing workspace from that workspace's members list. ## What's not in it yet The account list is paginated but has no search, which is fine at twenty accounts and annoying past a few hundred. There's no audit log, so the panel doesn't record who did what. Every flag is a simple on or off, with nothing per workspace. And one admin is one admin: no second role, no read-only view for someone who should see the instance without changing it. None of that blocks the thing the panel was for, so it shipped without them. --- This panel exists because someone asked for it in an email. If you self-host and something is broken, or you need something that isn't here, don't hesitate to write to me. Problems and suggestions are both welcome, and this is where they end up. The whole thing is on [GitLab](https://gitlab.com/140crafts/use-jinear) and [GitHub](https://github.com/140crafts/use-jinear). # Notes. The Last Missing Piece. URL: https://jinear.co/blog/notes-the-last-missing-piece/ Published: 2026-08-01 Tags: changelog, notes I'm not eager to add more main features to Jinear. A couple of months ago I cut projects, Pages, and chat precisely to stop doing that. So adding one now needs a reason. The reason is that documentation never had a home. It lived rent free on tasks: a description that was really a spec, a comment thread that was really a decision record, a task nobody would ever close because it was actually a document. Or it ended up as a `.txt` or `.md` file in file storage, which is fine for keeping a file and miserable for reading or editing one. Calendar, tasks, files, notes. Those four are the pillars, in my opinion. There is a long list of things left to work on in this product, but I don't think there's a fifth pillar on it. ## What's in it - **Notebooks**, private, invite-only, or open to everyone in the workspace. - **Nested notes.** Drag a note onto another to file it underneath, or onto a notebook to move it there. Moving a note takes its children along. - **Tags** per notebook, with colors. - **Rich text.** Headings, lists, checklists, tables, code, images. - **Offline drafts.** A new note gets a local document from the first keystroke. It saves to your device immediately and syncs when there's a connection, so a flaky network costs you nothing. The editor tells you which of those two it's doing. ## What's not in it yet There's no search. You can browse the tree and use tags, but you can't search notes by title or content. That bothers me more than it probably bothers you, and it's next. Notes also don't link to tasks or calendar events yet. They will. --- If you use it and something feels wrong, email me. That's how the last three self-hosting bugs got found. The whole thing is on [GitLab](https://gitlab.com/140crafts/use-jinear) and [GitHub](https://github.com/140crafts/use-jinear). # Release v0.1.1675. Self-Hosting Fixes: Uploads, Ports, and Reverse Proxies. URL: https://jinear.co/blog/self-hosting-fixes-uploads-ports-and-proxies/ Published: 2026-07-26 Tags: changelog, self-hosting This release is all self-hosting. Three bugs in the install path, and better documentation for putting Jinear behind a reverse proxy you already run. ## File uploads never finished Uploads could sit at zero forever and never complete. When you upload a file, Jinear hands your browser a temporary, permission-carrying link so the file goes straight to storage. That permission is tied to the exact address the file is sent to, and Jinear was issuing it for the address it uses internally while handing your browser a link to the public one. Storage refused every upload. The same mismatch quietly broke image and attachment downloads too. Jinear now issues that permission for the public address from the start. A side effect: it no longer contacts your files domain itself, so it doesn't need to trust the certificate on it. Self-signed certificates on internal networks work now. ## Ports and HTTPS are configurable The installer used to claim the standard web ports and always fetch certificates automatically, which made it impossible to install alongside an existing reverse proxy. It now asks which port to listen on, and whether it should handle certificates for you. Say no and it asks whether something in front of it already handles HTTPS, then configures everything else to match, including the details that used to break sign-in on plain-HTTP internal setups. Running on a non-standard port used to make the app show its "You're offline" page even when everything was running; that's handled automatically now too. ## Healthchecks work Jinear's main service reported itself unhealthy forever on a perfectly working installation, because its periodic self-check used a tool that isn't installed in that container. It checks itself with something that's actually there now. ## Better docs for reverse proxies - **A guide for running behind nginx**, with a config you can copy. nginx has two defaults that break file storage and the guide calls out both. One is worth repeating: the app and API will appear to work even when the files domain is misconfigured, so "the app loads" isn't proof that uploads will. - **What to do when your proxy is another container.** The older docs assumed your proxy reaches Jinear through a published port on the host. If it's a container on the same machine, it doesn't need to. That's documented now. - **What to do when your proxy has a UI instead of a config file.** If you run something like Nginx Proxy Manager there's no file to copy, so there's now a short section on what to actually click: three entries, all pointing at the same place, nothing else. --- All three bugs came from someone running Jinear on a real network, with their own proxy and their own certificates. I could have found them myself. I just hadn't tested far enough. If you're self-hosting and something is broken, or just confusing, email me. The whole thing is on [GitLab](https://gitlab.com/140crafts/use-jinear) and [GitHub](https://github.com/140crafts/use-jinear). # A Leaner Jinear: Dropped Features, a New PWA, and a Dedicated Site URL: https://jinear.co/blog/whats-new-leaner-jinear-pwa-and-marketing-site/ Published: 2026-06-10 Tags: changelog, architecture I've made some big changes to Jinear's shape. The short version: I cut features that pulled focus away from the core, and I split the old web app into two purpose-built frontends. Here's what changed and why. ## What I removed To keep Jinear focused on tasks, calendar, and file storage, I retired these features: - **Projects.** The project layer is gone altogether. Jinear now centers on tasks, calendar, and files without the extra project grouping on top. - **Project Pages.** Each project used to get a public/restricted feed, like a project's own profile or blog. The backing service is archived. - **Custom domains on project feeds.** With Pages gone, the on-demand TLS and Cloudflare DNS machinery that served custom project domains went with it. The gateway now runs stock Caddy. - **Chat.** Real-time messaging and its websocket service have been removed. They were the wrong fit. Self-hosted small teams tend to already live in an existing messaging platform, and expecting 3 to 5 people to move to another one just isn't realistic, so chat had to go. The same logic applied across the board: I'd rather do less, well. Instead of piling on more features, I want to polish the ones that are left, the core flows and the design, until they feel right. ## Two frontends instead of one The old `jinear-web` was a single Next.js app doing two very different jobs: serving the logged-in product *and* the public marketing pages. I split it. - **jinear-app** is the product, a Vite + React 19 single-page app, served as an installable **PWA**. It works offline, installs to your home screen, and ships its own manifest. The PWA install also replaces the old WebView mobile wrapper, so there's one less thing to maintain. - **jinear-site** (this site) is the public face, marketing pages, pricing, and the blog, built as a fully static Next.js export. Real pre-rendered HTML per route means better SEO and friendlier crawling for AI bots. The blog also moved here, from the old `blog.jinear.co` subdomain to `/blog`. I didn't find moving old blog posts here helpful since they are mostly about features that are gone, but they can still be accessed on [Jinear's X page](https://x.com/usejinear) or [my X](https://x.com/cagdasplus). ## Why it's better this way Splitting the apps lets each one do its job well. The product app can lean into offline-first PWA behavior without dragging marketing SEO concerns along; the marketing site can be pure static HTML without bundling the app's auth and state machinery. Self-hosters get a smaller, simpler stack, fewer services, stock Caddy, no archived dependencies. `jinear-web` is still around during the transition, but new work happens in `jinear-app` and `jinear-site`. Leaner, faster, and easier to run yourself. You can always check out whole repo at [Gitlab](https://gitlab.com/140crafts/use-jinear) and [GitHub](https://github.com/140crafts/use-jinear).