[HN Gopher] Show HN: Libredesk - Open-source customer support de...
___________________________________________________________________
Show HN: Libredesk - Open-source customer support desk. Single
binary app
Libredesk is a 100% free and open-source customer support desk, the
backend is written in Go and the frontend is in Vue JS with ShadnCN
for UI components. Unlike many "open-core" alternatives that lock
essential features behind enterprise plans, Libredesk is fully
open-source and plans to always stay this way. It's in alpha
(v0.1.0) right now, but there's a working demo available. I built
this because I wanted a truly open and self-hosted alternative to
platforms like Chatwoot, Intercom, and Zendesk. Would love
feedback, suggestions, and thoughts from the community. GitHub:
https://github.com/abhinavxd/libredesk Demo:
https://demo.libredesk.io/
Author : avr5500
Score : 350 points
Date : 2025-02-24 11:05 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| vishnumohandas wrote:
| Looks amazing, great demo!
|
| nit: it'd be nice if we could resize the sections
| mjoin wrote:
| Not in the domain but it looks great :) Congratulations
| mofirouz wrote:
| It would be wonderful if it could be used as a ticketing solution
| where the ticket could have severity. So customers could login to
| create a ticket as part of their org.
|
| Also data sources from either third party in-house database or
| something HubSpot would be great!
| teruakohatu wrote:
| When I last looked, I couldn't find any truely open source
| solutions that could practically replace even a shared inbox.
| This looks like it could. Well done to the developer.
|
| And the paid options had high costs even on the most basic plans.
| Aeolun wrote:
| Haven't really seen anything else but it certainly loads fast!
| TechDebtDevin wrote:
| Cool idea!
| d1sxeyes wrote:
| Looks great!
|
| Mobile experience is not great but I think it's sensible not to
| focus on that yet, the number of users doing customer support
| from a mobile phone is pretty small, even the big players in this
| space like ServiceNow etc have suboptimal mobile experiences.
|
| Do you have any plans on how to monetise this or is this a labour
| of love?
| avr5500 wrote:
| Mobile is not the focus, it can be done later as an app or
| something else. No plans to monetize; yes, it's a labor of
| love.
| d1sxeyes wrote:
| Lack of a monetisation strategy is a concern for folks who
| might worry that you end up running out of time/motivation to
| work on it, which might be a roadblock to wide adoption
|
| That said, if you're only in it for the joy of creating
| something amazing, and don't really worry about whether
| you'll be able to keep maintaining it indefinitely, then keep
| it up!
| techn00 wrote:
| I love single binary apps, easy to deploy.
| hamdouni wrote:
| It still needs postgres and redis
| grzaks wrote:
| Excellent! I was looking for a lightweight OSS alternative to
| Freshdesk/Zendesk and, honestly, didn't find any worth deploying.
| Yours looks very promising, and we'll definitely assess it.
| yorwba wrote:
| I don't know how lightweight you're looking for, but you might
| also want to have a look at Zammad:
| https://github.com/zammad/zammad I worked with a self-hosted
| deployment of it before, and it was reasonably low-maintenance.
| oever wrote:
| Does it support the scenario where part of the team is only on
| IMAP?
| pentacent_hq wrote:
| Great job, that's looking very nice and polished already! Are you
| also planning to introduce a SaaS version of it?
| avr5500 wrote:
| No plans, cloud deployment platforms like Railway can take of
| it
| nh2 wrote:
| How do you plan to fund the development, if at all?
|
| For a project like this, a hosted version might be a nice
| idea if you eventually want to do something else than putting
| your free time into support and maintenance. And many users
| will appreciate that the hosted version takes care of DB
| migration and backups for them.
|
| A hosted version need not necessarily target maximum money
| making. You could run it as a nonprofit whose goal is to
| ensure that the open-source project works well and lives
| long.
| avr5500 wrote:
| > A hosted version need not necessarily target maximum
| money making. You could run it as a nonprofit whose goal is
| to ensure that the open-source project works well and lives
| long.
|
| That actually makes sense.
|
| Also will apply to FOSS funds like - https://floss.fund
| nh2 wrote:
| For an example of how it can go down otherwise:
|
| papercups.io - Open-source alternative to Intercom
|
| Funded by Y Combinator
|
| https://web.archive.org/web/20230404011725/https://paperc
| ups...
|
| https://news.ycombinator.com/item?id=26527268
|
| https://news.ycombinator.com/item?id=24133719
|
| I don't know why it shut down (my guess: didn't pan out
| with the typical revenue growth goals of a startup), but
| having a hosted version might save your project from such
| fate, making enough money to fund you, or somebody you
| hire who's excited about working on Free Software.
|
| Some pricing ideas: Free for noncommercial with limited
| data retention (like the Chatwoot free tier), 3-5 $/month
| for noncommercial individuals (e.g. users to put it in
| their website), more $/month for commercial. Add some
| more expensive enterprise plan that supports Microsoft
| EntraID groups for externalised permission management and
| you're good to go :) Add easy DB import/export
| functionality, so people can switch between hosted and
| self-hosted. A lot of people will be happy to pay for the
| convenience of hosted. Host in EU for best data
| protection (makes it easier for people to sign up).
|
| For billing, probably good to use a Merchant-of-Record
| service such as paddle.com (our startup likes it) to be
| able to sell internationally without having to deal with
| international taxes.
|
| I wish you and the project lots of success!
| Jolter wrote:
| Would hosting in Europe really help?
|
| I'm under the impression that current EU case law makes
| it impossible for EU-based government entities to store
| personal data in services _owned_ by US entities, no
| matter where they are hosted.
|
| Maybe I misunderstood this?
|
| Someone has told me that all the EU governments using
| Office 365 are basically violating the GDPR and getting
| away with it (for now). Any truth to that?
| rancar2 wrote:
| Chatwoot's free hosted tier has limited data retention
| and only offers US-based data centers. However, its core
| functionality can be self-hosted anywhere under its MIT
| license.
|
| For the OP: nh2's advice above is worth considering.
| Additionally, I'm not sure Libredesk is mature enough to
| be a strong open-source alternative to Chatwoot yet--
| unless the user only needs email support. Chatwoot's base
| installation, licensed under MIT, includes most of the
| features non-corporate users would want, such as multi-
| channel support, and generally offers more functionality
| than Libredesk under its AGPL license.
| potamic wrote:
| Who are your target users? Why not use an embedded db like sqlite
| and make it truly "single binary"?
| codazoda wrote:
| I would dig this
| truepath_app wrote:
| I might be missing something obvious, but how does a customer
| file a ticket/request?
| avr5500 wrote:
| Right now the only way to create a ticket/request is by adding
| an inbox, and sending an email to your configured email
| address.
| nh2 wrote:
| Looks great!
|
| It seems to be email only so far. Do you plan to add chat, like
| Intercom and Chatwoot have it?
| avr5500 wrote:
| yes, once Libredesk is stable.
| duckb wrote:
| Looks beautiful. How difficult would it be if I want to develop a
| plugin - Mood detection, Chat Helper (LLM linked), ...
| ketan-10 wrote:
| Looks awesome, Congratulations :)
| darkwater wrote:
| The demo looks really really good! And by looking at commit
| history, looks like you are a solo developer behind this. Kudos
| to you! Out of curiosity, do you have plans to make it a business
| or just keep it as a "hobby project"? Something like this is
| going basically to be used only by companies, no hobby users
| (unless someone wants to maintain a support desk for family &
| friend about something they are an expert...)
| chrismorgan wrote:
| From the screenshot, in an AI assistance dropdown on a reply
| form: "Add Empathy". _Ouch._
| ddtaylor wrote:
| Abolish corporate communication apathy, but don't point the
| finger at a dictionary as the reason it exists.
| fguerraz wrote:
| This is great.
|
| Sadly, apart from "looking good", there seems to be no
| documentation, or visible roadmap. So I can't evaluate if it's
| worth looking into or not.
|
| Keep up the good work!
| avr5500 wrote:
| Thank you! Adding a roadmap to v1.
| mattsimpson wrote:
| Damn impressive start. Kudos! I am sure that if you posted a to-
| do list and roadmap to 1.0 you would get traction from the
| community to help finish it off, if you want. Hell, at a solid
| 1.0 I might be able to justify a switch from a popular commercial
| app and use that budget to fund a bit of development towards the
| project.
| avr5500 wrote:
| Thank you! Adding a todo and a roadmap to v1.
| robertlagrant wrote:
| Potential roadmap item: bidirectional sync with Jira (and others)
| so support requests can create/be linked to Jira (etc) tickets,
| and see updates from them.
| phrotoma wrote:
| While we're thinking about it, something I always wanted when I
| was working support. The abilitiy to "upvote" a bug from within
| a support case. That way a PM can sort open issues by number of
| users who are griping about it.
| robertlagrant wrote:
| Yeah! Or at least have a count of the number of customer
| requests linked to the same ticket.
| rsyring wrote:
| We looked years ago for simple helpdesk that would link to
| GitHub issues so that CS was working in the helpdesk tool but
| could easily create issues when a dev is involved.
| srameshc wrote:
| Nice name , looks great and very useful !! How you built a single
| binary of Go and Vue is very neat, I never thought about doing
| something like this.
| KingOfCoders wrote:
| This is also something I love about Go,
|
| https://www.inkmi.com/blog/simplicity-of-golang-systemd-depl...
| srameshc wrote:
| thanks for sharing, there is always something to learn
| ddtaylor wrote:
| What method do we have to fund this or ensure it can work for our
| needs.
| revskill wrote:
| Single app meanz j bundle all asset and code in a binary?
| dinu99 wrote:
| Looks nice, congratulations. Can you add knowledgebase section?
| I'm looking for an alternative to freshdesk/zendesk. I would
| recommend monetizing this via hosted service like
| https://frappe.io/ does with ERPNext project.
| yashasolutions wrote:
| Nice work. I cannot test the demo as it is down now but just
| wanted to share I have been using open source solution Zammad and
| I am pretty happy about it. It's fully open source (it's a ruby
| app - so different stack.) and pretty robust. The frontend is a
| bit oldish, but it has a lot of nice features. The single binary,
| easy deploy + fresh UI is interesting thought. Are you planning
| multilingual features?
| avr5500 wrote:
| It's up now, yes planning to support multiple languages.
| calvinmorrison wrote:
| Anyone using RT still here?
|
| My idea tracking system is one that exists in email, but doesnt
| send a billion obnoxious "your ticket has been created" emails
| and butcher the contents. So far I've got it kind of working with
| RT as a no reply listener. We watch all comms but it doesnt reply
| to anything.
| curtisszmania wrote:
| We all know open-source customer support tools are still the wild
| west, and Libredesk might just be the sheriff in town.
|
| Libredesk's single binary app approach is refreshing - simplicity
| can be beautiful when done right.
|
| As someone who's been around the block a few times, I'm intrigued
| by the potential for self-hosted support desks to disrupt
| traditional SaaS models.
|
| In fact, I remember when our own company was small and struggled
| with customer support. We ended up building something similar to
| Libredesk, but it took us months of trial and error - not exactly
| scalable.
|
| So kudos to you, abhinavxd, for creating a tool that could
| potentially make all our lives easier (or harder, depending on
| how we choose to use it).
| mouse_ wrote:
| If the AI response feature promises something I cannot deliver,
| who is liable?
| rad_gruchalski wrote:
| You are.
| snvzz wrote:
| Mandatory Affero GPL warning.
|
| Ensure you understand the license before deploying.
| rancar2 wrote:
| Chatwoot has a lot more features with its MIT license.
| mr-karan wrote:
| I'm curious to understand the implications of the AGPL-3.0
| license in the context of this project. It sounds like the
| author doesn't want big corps to offer a hosted version of this
| tool (because doing that would require them to release the
| source code of any modifications they make to the software,
| which many companies are reluctant to do) and it's also an OSI
| approved license (unlike the recently famous SSPL or BSL).
| What's so wrong about AGPL-3.0 then?
|
| The intention is often to prevent companies from building
| proprietary services on top of open source software and I feel
| AGPL 3.0 is a sensible choice here.
| firefoxd wrote:
| Kudos! We've encountered several customers that hated their help
| desk but couldn't move away. We've even considered building our
| own since we were in the business. But here comes the hard and
| most important part that Zendesk and the like do that makes all
| the difference: Integration.
|
| You need support integration with all the popular tools people
| use their help desk with. Shopify, ebay, whatsapp, woocommerce
| and all the seemingly unrelated software people use to support
| their e-commerce business. That's where we gave up, but I hope
| you find a solution for it.
| aarreedd wrote:
| Surprised no one has mentioned FreeScout. It's a solid open-
| source helpdesk: https://freescout.net/.
|
| They have cheap, one-time purchase plugins. Happy to pay a bit to
| keep the project sustainable.
|
| I'd love to see an open-source Trello alternative that as well.
| There are a few out there, but nothing that seems actively
| maintained.
| alchemist1e9 wrote:
| https://github.com/RotherOSS/otobo
|
| Otobo might be a good other option. It's a refreshed and
| expanded version of the classic OTRS. Yes perl, but in this
| space has an extensive track record.
| qwertox wrote:
| This looks _very_ promising. Does it have an API?
| avr5500 wrote:
| Thanks,
|
| Yes I will adding an API user support, you will be able to
| interact with Libredesk with APIs.
| registeredcorn wrote:
| It's a neat idea and I'd like to see how this evolves over time!
| Keep up the great work!! :)
|
| I do have notes/feedback based off of what I see in the demo
| site:
|
| # SLA
|
| The SLA stuff under the Admin panel needs to be way, _way_ more
| robust if I were to ever use it. Many of the clients I work with
| have different SLA expectations based on the _severity_ of an
| issue. They also might work in different time zones from Support
| staff, so calendars may need to be set to "countdown" in
| relation to either client local time, or support local time,
| depending on what is decided in the contract. In addition to time
| zone stuff, there's _also_ issues with what constitutes a
| holiday; we may have holidays that they don 't, or vice versa.
| Unless something is covered under a niche 24/7/365 contract _and_
| is marked as Critical, we wouldn 't want the "countdown" to
| trigger until the next business day. This matters a lot, because
| many US holidays are on Friday, so tickets will go unanswered for
| 3 full days.
|
| Here's an example of multiple, different SLA requirements for one
| client:
|
| * A Critical should have a response within 1 hour (24/7
| coverage), and a resolution within 12 hours (24/7 coverage).
|
| * A Low should have a response within 5 business days, and a
| resolution within 30 business days.
|
| Now imagine that, but multiplied by many, many clients. Instead
| of having however many SLAs for each situation per client, we
| like to have "compact" SLAs where there are clauses for different
| severity ratings of a ticket, and factoring in a bunch of other
| stuff, for individual clients. Client 1 paid for 24/7 for
| criticals, but not other stuff, so Client 1 SLA is (this). Client
| 2 paid for 24/7 for all things, so Client 2 SLA is (that). Client
| 3 paid for the most basic coverage, so Client 3 SLA is (the
| other).
|
| We would need an SLA system that accounts for various factors and
| verbiage within a ticket received. Sometimes it also depends on
| _who_ files the ticket with us. Is it the "problem child", or is
| the CEO?
|
| # Time zone (as it relates to SLAs)
|
| In the contract, it is usually formally agreed that if no support
| staff lives in the clients local time zone, then the SLA response
| time will not start counting until it applies to the support
| staffs local time zone. Exceptions are made if they pay for
| 24/7/365 coverage. So, even if support receives two different
| "important" tickets from two different clients, one may take
| priority over the other because the service coverage they have
| paid for.
|
| ## Example(s):
|
| * Client 1 files a ticket at 2PM their time; no 24/7 coverage.
| It's 4AM for local Support. Support's response time doesn't
| "start the countdown" until 8AM in Support's time zone.
|
| * Client 2 files a ticket at 11AM and is supposed to have a
| response time within 4 hours; no 24/7 coverage. The ticket is
| filed on July 4th (Independence Day in the US) for the Support
| staff. The 4 hour "countdown" doesn't start until 8AM on July
| 7th. (3 day weekend)
|
| * Client 3 files a ticket at 2PM on July 4th; have 24/7 coverage.
| It's 4AM for local Support on July 4th. The "countdown" has
| started.
|
| # Holiday
|
| It would also be nice if the option for "New Holiday" adjusted
| automatically each year. We have a fair number of clients, and
| manually updating Holiday's consistently (and accurately) is not
| something I see people doing particularly well at the start of
| each year. It's kind of one of those things you end up catching
| around September, and realize all of your metrics for the last
| few quarters have been off.
|
| # FRD and RD text?
|
| In the conversation with Felix Morin, I see warning labels for
| "FRD Overdue" and "RD Overdue". What are those triggered by? I
| didn't see anything in the admin area that seemed to point to it.
| It would be good if, on hover, it would give a brief explanation
| of what the trigger is. Or is it something that the person who
| filed the ticket did, somehow?
| avr5500 wrote:
| Hey, thank you for taking time to write such a detailed
| feedback! Really appreciate this.
|
| The automations are just for that, in automations admin tab you
| can create rules like email has text `@google.com`,
| `ceo@xyz.com`. If true you can apply certain actions like set
| SLA, assign to a specific agent, etc.
|
| You're right this SLA system is not flexible enough, I will
| work on improving this feature.
|
| Regarding the "FRD Overdue" and "RD Overdue" labels, they show
| when the First Response Deadline or Resolution Deadline for a
| ticket has passed. Yes adding some hover text makes sense.
|
| Maybe the https://libredesk.io/docs page needs a concepts
| section.
|
| Again thank you for the feedback.
| crazymoka wrote:
| When it turns to beta, I'll be using this.
| gregoriol wrote:
| Interesting project!
|
| However, installation documentation is quite strange: it says
| "requires postgres and redis to run" but there is zero other
| information. Is there any version requirements? any configuration
| file to set the hosts/auth for them?
|
| Hope this helps, keep the good work!
| avr5500 wrote:
| The Docker file specifies versions:
| https://github.com/abhinavxd/libredesk/blob/main/docker-comp...
|
| I will include the versions in the installation docs for binary
| installations. Thanks for the feedback.
| yoeven wrote:
| Are there plans for future integrations into messaging platforms
| like Whatsapp or Telegram?
| wiradikusuma wrote:
| The UI looks good! I can't seem to find the channels it supports.
| Email? X? Instagram (IG) comments?
|
| A support desk is all about channel integrations, for example:
|
| - replying IG comments from the app
|
| - replying Telegram chats from the app
|
| - replying support@myco.com from the app (SMTP & IMAP
| integration)
|
| - basic CRM so that we that the customer doing all 3 above are
| the same, so the agent has "context"
|
| - integration with external CRM
|
| I hope I'm not offending anyone, but if any integrations are
| supported, you should emphasize this.
| OldMatey wrote:
| Fantastic. This is far overdue and looks like a solid start. I
| have been particularly surprised by how few options there are in
| the CS space that are open source and options like Zendesk are SO
| expensive and the pricing tiers and cost structures are
| prohibitive for many small organizations.
| remram wrote:
| Looks good! I'm currently using OsTicket (PHP) with a small team.
| Pretty happy with it but could use more automation. What I like
| best about OsTicket is that I was able to configure it completely
| transparent, there are no auto-messages sent to users and no
| reference numbers of boilerplate in outbound messages.
|
| Happy to see more opensource options in this space, especially
| with a focus on customizable automation.
___________________________________________________________________
(page generated 2025-02-27 23:01 UTC)