motakuk

Hi HN, Matvey from Archestra here.

Recently, OpenAI shipped "Sites", a mini-apps AI builder. It's similar to "Databricks Apps" or Loveable.

We worked on this concept for the last few months, and tried to approach it from the most "open source friendly" and interconnectable way, providing the ability to build mini apps re-using the MCP data layer, re-using MCP authentication while accessing those apps, and also exposing those apps as MCP servers themselves so they could be utilized through the 3'rd party clients like Claude Code.

We'd love for you to take a look at the repo, try it out, and give us your feedback!

GitHub: https://github.com/archestra-ai/archestra

We do, it's a part of our hiring pipeline: https://archestra.ai/careers

Would love to! Could you please share more? I can't quite see the issue

At the end it's a company choice: do you buy BS metrics or you don't.

We've recently decided to complicate life of AI bots in our repo https://archestra.ai/blog/only-responsible-ai, hoping they will just choose those AI startups who are easier to engage with.

LightRAG, Archestra as a UI with LightRAG mcp

To some extent, but not 100%. We're working on several ideas in this direction, which we plan to include in the upcoming release. This includes the dual-LLM pattern and providing manual reviews for pinned versions of the open-source MCP servers.

For now, Archestra is categorizing tools and preventing the execution of tools that could leak data to the outside world without consent. Asking for permission for all tool calls may lead to fatigue; not asking for consent will expose the agent to the attack, so we're trying to strike a balance.

Hi Hacker News! Matvey, Ildar, Joey, and Dominik here. Anthropic introduced the Model Context Protocol (MCP) almost a year ago, and the community has built thousands of open-source MCP servers, but there are a few issues.

Local MCP servers are executables, and running straight from GitHub is quite dangerous. Also, to start the local MCP server and connect it to, for example, Gmail, one needs to register a Google Cloud account, issue a file with OAuth tokens, place it in a specific directory, and set the environment variable.

We built Archestra, a simple desktop orchestrator for open source MCP servers, enabling you to install and use self-hosted & remote MCP servers with just a few clicks. It's running local MCP servers in a Podman sandbox to prevent access to the host, dynamically adjusts the set of enabled tools, and maintains permanent memory. Most importantly, it handles authentication through the UI via OAuth or by retrieving API keys from the browser and launches MCP servers accordingly.

Archestra is open source and MIT: https://github.com/archestra-ai/archestra

A short demo, using GitHub, Gmail and Slack MCPs: https://www.loom.com/share/84ea6a684f014ebba5e39dd0dd0242a2

You can try it yourself by downloading the app and using it with local models, OpenAI, or some of our free tokens: https://archestra.ai.

OSS <3

Regarding the "1% of cyanide" comment, I’d like to share another perspective :)

Almost every tech company has private code—typically stored in private repositories. When working on Keep, we faced a decision: should we place certain code in the EE folder under a different license or keep it in a private repo, only sharing it with a small group of enterprise customers who explicitly requested it?

We chose to put that code on GitHub.

Ironically, putting more code in the GitHub repo made it appear "less open source," even though we could have simply hidden it, making the repo look like "clean OSS" as multiple companies do. For example, those who put their products without Web UI to the open source, build UI privately and serve the "full" version in the cloud.

Companies adopt different strategies when building Open Core products. Some aim to keep the Open Source portion minimal, reserving the most valuable features for their paid versions. At Keep, we chose the opposite path—moving nearly everything into Open Source. Our philosophy is that most users should be able to fully benefit from the Open Source version.

While I understand (and share) the caution around licenses, I don’t think this concern applies to Keep. With 99% of our codebase under the MIT license, it’s a far cry from just having "parts of the code with an open source license."

I recommend running Keep locally and comparing the Open Source version to the playground where full version is running. You might find it challenging to spot the differences.

I also reccomend comparing Keep Open Source to BigPanda and Moogsoft. It may be surprising how much of it Keep OSS, real MIT-licensed Keep has.

Deployment with Nomad should be pretty straightforward following https://github.com/keephq/keep/blob/main/docker-compose.yml or https://github.com/keephq/helm-charts

It's gone because it was barely usable.

It also works with other alert sources like DataDog or Zabbix.

Check this ;) https://github.com/grafana/oncall/tree/dev/tools/pagerduty-m...

I agree that multi-component architecture is harder to deploy. We did our best and prepared tooling to make deployment an easy thing.

Helm (https://github.com/grafana/oncall/tree/dev/helm/oncall), docker-composes for hobby and dev environments.

Besides deployment, there are two main priorities for OnCall architecture: 1) It should be as "default" as possible. No fancy tech, no hacking around 2) It should deliver notifications no matter what.

We chose the most "boring" (no offense Django community, that's a great quality for a framework) stack we know well: Django, Rabbit, Celery, MySQL, Redis. It's mature, reliable, and allows us to build a message bus-based pipeline with reliable and predictable migrations.

It's important for such a tool to be based on message bus because it should have no single point of failure. If worker will die, the other will pick up the task and deliver alert. If Slack will go down, you won't loose your data. It will continue delivering to other destinations and will deliver to Slack once it's up.

The architecture you see in the repo was live for 3+ years now. We were able to perform a few hundreds of data migrations without downtimes, had no major downtimes or data loss. So I'm pretty happy with this choice.

Fixed: https://grafana.com/docs/grafana-cloud/oncall/

We're fixing that, thank you ;)

Hello HN!

Matvey Kukuy, ex-CEO of Amixr and a head of the OnCall project here. We've been working hard for a few months to make this OSS release happen. I believe it should make incident response features (on-call rotations, escalations, multi-channel notifications) and best practices more accessible to the wider audience of SRE and DevOps engineers.

Hope someone will be able to finally sleep well at night being sure that OnCall will handle escalations and will alert the right person :)

Please join our community on a GitHub! The whole Grafana OnCall team is help you and to make this thing better.

Please reach out to me, it would be awesome to learn your experience of using our API and make sure we're aware of all bugs you noticed (and fixing them!), matvey.kukuy @grafana.com

It's 100% part of the Grafana Cloud, not a separate product. It's deeply integrated with the rest of Grafana.

Same time we've focused on making it useful for those who don't use Grafana for monitoring. Feel free to sign up in the Grafana Cloud and use just OnCall if you want.

For now, we are focusing on rolling Grafana OnCall in the Grafana Cloud. It's a very common use case to have such a system outside of your infrastructure so it won't be affected by probable issues. It should be alive even when everything goes wrong.

We've already received multiple questions about OSS and on-premises. Will roll cloud version first, see how it works, collect feedback and build (and share) future plans!

Yep! The idea of Grafana OnCall is to help you to group, deduplicate, route & deliver to Slack/SMS/Phone alerts from any sources. It could be a CloudWatch, DataDog, self-hosted Alertmanager, or Grafana of course. The only requirement for the alert source is to be able to generate a webhook and send it to us.

Hey everyone, Matvey, ex-CEO of Amixr is here. Me and Ildar Iskhakov started this project three years ago because we used to be on-call ourselves and needed better tools. It was an amazing journey from 0 to 1. Tons of coding, first customers, fundraising, iterating, and finally the honor to join Grafana Labs and build Grafana OnCall! I'll be happy to answer your questions if you have any.

There is one more concept in this field: agree with collaborative nature of incidents and work with them in Slack directly (implemented in https://amixr.io)

1) Have a monitoring in place. 2) Never miss alerts, use smth with multi-channel escalation like amixr.io

I'm a Slack App developer (http://amixr.io incident management), we have a client who added us to their Slack and it changed a lot. Seeing how users collaborate with your app (and next to your app) gives us a lot of insights.

Shared Channels could make such experience of sharing channels between bot developers and users more common.

The moment you need no know about outage really fast (ideal case for amixr.io)

Ghost in Docker deployed with Ansible. Default theme: https://mku.life/ (Russian)

For most of businesses it's too pricy to write a good one. Also it's too pricy to have a bad one.

Consider using SaaS like Constructor.IO, algolia.com etc.

Thanks!