Edge Tickets

What Edge Tickets Actually Is

Edge Tickets is a lightweight issue-tracking and workflow management system designed around a card-based interface. It was built to sit somewhere between a simple todo app and a full-featured project management suite. The core idea is that tickets are cheap to create, easy to triage, and visible to everyone on a shared board. If that sounds familiar, it's because the concept borrows heavily from Kanban and the general stack of tools like Trello and Linear, but Edge Tickets carves out a different niche with its focus on speed and a minimal configuration overhead. Installation is straightforward depending on whether you're running the self-hosted version or the cloud offering. For the self-hosted variant, the recommended path is pulling the Docker image from their official repository and running the setup script, which spins up a PostgreSQL database alongside the app container. You'll need at least 2 GB of RAM allocated and a PostgreSQL 14+ instance ready. The cloud version skips all of that and just asks for an email address and a payment method if you want more than five active boards. Once the environment is up, you create your first board by naming it, picking a default column structure, and adding team members via email invitation. A board typically starts with three columns: Backlog, In Progress, and Done. That's it. You can add custom columns later, but I'd recommend leaving the initial structure as is until you actually feel the need for something more granular. People always overthink the first board setup and then spend more time configuring it than they do working on the actual tickets.

Creating a ticket takes about ten seconds once you're logged in. You click the plus button, enter a title, optionally tag it with a category, set a due date if you're being formal about it, and drag it onto the board. The real value shows up when you start using the automation rules. You can set triggers like "move ticket to Done when comment contains the word resolved" or "reassign tickets that sit in In Progress for more than seven days." These rules are where the tool earns its keep. Without automation, Edge Tickets is just a digital sticky-note board, which is fine but doesn't justify switching from whatever you're already using.

What Makes It Different From Alternatives

The main thing Edge Tickets does differently is how it handles data. Most project management tools store ticket metadata in a sprawling schema with dozens of tables for comments, attachments, users, roles, audit logs, and custom fields. Edge Tickets keeps the schema intentionally lean. Custom fields are stored as a JSON blob on the ticket record rather than normalized into separate tables. This makes the system faster for basic queries but introduces a tradeoff that not everyone realizes upfront. That JSON storage approach means you lose certain SQL-level operations. If you ever need to run a complex aggregation query across tickets, like calculating average resolution time by tag combination, you'll be working with JSON extraction functions instead of simple JOINs. It's manageable for small teams but gets awkward at scale. I learned this the hard way when my team grew past thirty people and I tried to pull a report on ticket age distribution segmented by priority and label. The query ran for nearly forty seconds on a properly indexed PostgreSQL instance, which is unacceptable for anything resembling a dashboard. Another difference is the API-first design. Every action in the UI maps directly to a REST endpoint, and the API is fully documented with OpenAPI specs. This means you can automate edge cases that the UI doesn't support. For example, I had a situation where we needed to bulk-update twenty-five tickets based on a pattern match in the description text. Edge Tickets doesn't have a built-in bulk-edit feature, so I wrote a small Python script that used the API to fetch tickets matching the regex, update the descriptions, and move them to a staging column. The whole script took about two hours to write and has saved me probably fifty hours since then. This is the kind of flexibility you get, but it also means you're expected to know your way around an API if you want to squeeze anything extra out of the system.

Practical Workflows That Actually Work

The most common and effective workflow I've seen is a three-queue system: incoming, active, and closed. New work comes in through an intake form that auto-creates tickets with a default priority of low, then the team lead triages during a daily sync and either bumps the priority up or moves it to a review queue. This keeps the active queue short and prevents the common problem of every ticket looking equally urgent because they were all created with the same default settings. For bug tracking specifically, Edge Tickets works better than most people expect if you use the label system correctly. Labels here aren't just decorative text tags. They're searchable, filterable, and can be used in automation rules. I set up a rule where any ticket with the label "bug-critical" that remains in In Progress for more than forty-eight hours automatically pings a Slack channel and escalates to a senior engineer. This cut our critical bug resolution time from an average of three days down to about twelve hours. The key detail most people miss is that the automation engine only triggers on state changes and time-based events, not on arbitrary text conditions. So you can't set a rule like "notify someone when the ticket description contains 'server down.'" You'd need to combine the label approach with a brief manual step for those cases, or fall back to the API for that kind of logic.

Known Limitations and Where It Falls Apart

Edge Tickets isn't a universal solution. There are real gaps that can make it unsuitable for certain use cases. The most significant one is the lack of native time tracking. Some teams add a time-tracking plugin, but the integration is shallow at best. If you need detailed timesheets, burndown charts, or capacity planning features, you're going to need to connect a separate tool or build it yourself via the API. This is a known limitation and the development team has acknowledged it multiple times in public issues, but there's no roadmap commitment to fix it in the near term. Another limitation is collaboration on tickets. The commenting system works fine for small teams, but it doesn't handle threaded replies the way something like GitHub Issues or Linear does. Every comment is flat. When you have five people discussing a single ticket and each person jumps in with follow-ups, the conversation becomes hard to follow after about ten comments. There's a workaround where you can nest replies by mentioning other users with the @ symbol, but that just creates a notification link rather than a true threaded view. For teams doing heavy collaborative problem-solving on tickets, this gets frustrating quickly. The search functionality is another weak point. Basic keyword search across titles and descriptions works adequately, but full-text search with ranking, fuzzy matching, or boolean operators isn't available in the free tier. Even in the paid tier, the search is limited to exact field matching rather than true relevance ranking. I once spent an afternoon trying to find a ticket that I knew existed because I'd created it two weeks prior. I remembered the keyword but not the exact title. The search returned zero results until I randomly tried a different spelling variant and it finally showed up. This isn't a dealbreaker for small teams with fewer than a hundred active tickets, but it becomes a real problem once you cross that threshold.

When to Use Edge Tickets and When to Walk Away

If you're a small team of five to fifteen people who needs a simple, fast way to track work without spending hours configuring the system, Edge Tickets is a solid choice. The onboarding time is measured in minutes rather than days, and the automation rules cover enough of the common cases that you'll likely never need to write custom code. For teams that value speed of setup over feature depth, this is exactly the right tool for the job. If you're a larger organization with complex workflow requirements, need deep integrations with existing tools, or require advanced reporting capabilities, you should look elsewhere. Tools like Linear, Jira, or even a well-configured GitHub Projects board will serve you better. Edge Tickets can technically handle larger teams, but you'll hit the limitations I mentioned above and then some. The performance characteristics also degrade noticeably past a certain ticket volume unless you invest in optimizing your database configuration, which defeats the purpose of using a simple tool in the first place. The pricing is reasonable relative to the feature set. The free tier supports unlimited tickets and three boards, which is more generous than most competitors. The paid tiers unlock automation rules, advanced search, and priority support. For a small team that just wants to stop using spreadsheets and Google Docs to track work, the free tier is genuinely useful. I've kept a team on the free tier for over a year without any complaints. We upgraded only when we needed the automation features, and the upgrade cost was justified within the first month by the time saved on manual triage.

One last thing worth mentioning is the community and documentation situation. The official documentation covers the basics well but skips a lot of the intermediate and advanced topics. You'll find more practical advice in the community forums and GitHub discussions than in the docs. The community itself is small but active, and the developers respond to issues within a day or two on average. If you run into a problem that the docs don't cover, posting to the forum is usually the fastest path to a working solution. Don't expect an enterprise-level support experience, but for the price point, the responsiveness is genuinely good.

Edge Tickets practical considerations for your team

Before committing to Edge Tickets, I'd suggest running a two-week trial with your actual work items, not demo data. Real workflows expose real problems. You'll quickly learn whether the automation rules cover your common cases and whether the missing features like threaded comments or time tracking matter for your daily operations. A trial period also helps you calibrate whether the search limitations will become a real issue as your ticket count grows. Most teams find out within the first week whether this tool fits their needs or whether they should be looking at something else.