We’ve just begun implementing Composio. Would love to reconsider if you help clarifying the main differences. From my perspective it looks like you have more robustness features to me as a developer and you’re fully open source (not just the client) whereas Composio has more integrations. But would love your input to clarify.
Congrats on the launch!
Wen here, the co-founder. I actually spent a couple hours today to take the time to give you a comprehensive answer.
1. As you said, Composio doesn’t allow self-hosting and the source code isn’t available. We want to follow PostHog’s playbook in letting devs run everything on their own infrastructure and open sourcing all our MCP containers.
2. A huge benefit of this approach is that we can let you fork any MCP server through our dashboard so that you can manage it yourself and make any adjustments you might need. We’ve heard the importance of doing this repeatedly from our enterprise customers.
3. I do believe that we offer more robustness features, like environment provisioning, deployment versioning, server pooling, in-depth logs of server startup, as well as a complete trace of the entire MCP session.
4. On the integrations side, Composio does indeed have more integrations right now, but we already have around 600 MCP servers (all with multiple tools of course) of which many are being modified by us every day to make them better. Since we support open source contributions, the catalog also grows with the community. (Quick note that you can have private servers scoped to your org).
5. I tried to benchmark our architecture vs Composio’s in terms of speed. As we mentioned in the post above, one thing that we spent a lot of time on was optimizing how fast we can do serverless with MCP servers. However, since Composio has neither source available nor any technical documentation on how they handle their servers, I couldn’t actually find any information on their architecture. One thing that they enforce as default is having a meta-tool layer with tools like composio_search_tools and composio_execute_tool. Assuming that this is a long living process, I still found that our implementation returned a list_tools response quicker (including the cold start time). If you factor in the time that it takes for them to find the right tools, their response took close to double the time. While we might explore a similar meta tool layer as an optional MCP server in the future, we do seem to on average have a better architecture in terms of speed, though the benchmarking was not entirely rigorous. (I am also unable to answer how they handle multiple users connecting to one MCP server with different OAuth configs because they don’t share that information). I plan on making a more rigorous comparison in a blog post soon, also comparing to hosting on Vercel, Cloudflare, etc..
Wow, thanks a LOT for that comprehensive answer! Very helpful!
Two questions I didn’t manage to find answers to:
* Do you have or plan support for webhooks? The scenario for us is that we’d ideally have one platform for setting up customer integrations for which we will make requests to and await request from
* When you host, do you expose the access and refresh tokens for the connected integrations? The use cases for us are:
* If we wanna make a feature / request that seems out of scope for Metorial
* If we wanna migrate from Metorial, we don’t want to force our customers to have to reconnect
* I love that we can bring our own OAuth apps which would be the default for us. But to try out an integration out or for (from our perspective) low prio integrations we’d still like to offer - do you offer your own OAuth apps that we can piggy back on. Just to save the customer from the effort of having to set up an OAuth apps foe each service. I know it comes with a lock in, but it’s worth it in some cases for us.
You’ve made me very excited to try you out, so I’ll implement support for both Composio and Metorial.
Thanks again for taking the time and efforts to answer so thoroughly!
Love the idea, how you present it here and in the product. Clear, trustworthy and calming. Just installed and looking forward to try out. Half-random question: how has your way to the current UI / UX (visually and copy)?
I was able to request both new models only in Oregon / us-west-2.
I built a Slack bot for my wife so she can use Claude without a full-blown subscription. She uses it daily for lesson planning and brainstorming and it only costs us about .50 cents a month in Lambda + Bedrock costs. https://us-west-2.console.aws.amazon.com/bedrock/home?region...
naah, i always roll my own. I don't like pre-built stuff especially when you work with custom designs. I don't use css crap either like scss or tailwind, just vanilla js, css and html as it should be.
It's pretty incredible. Good documentation, easy to use, but still very powerful and extensible. Every component and prop can be overridden and modified when necessary, but the defaults make sense too.
I use it for every project now and it takes only a couple hours to get a functional MVP up and running.
MUI is really what sold me on the potential of the React ecosystem. It's so much nicer than writing HTML when you can actually compose an entire app out of widgets in a documented, vendor-supported way.
Love the design and your way of communicating!! You just made me a fan of you and your product.
My personal flow to love your product was:
1. I was intrigued to click this HN due to an initial feeling of the product must be more interesting than the HN title due to all the attention, so let’s check it out.
2. Once on the site I was feeling “finally someone who dares not having consensus driven design”.
So please keep on daring!!
3. I thought “I know people who would love this design”.
4. Being a person often being asked to build friends’ sites and way to often having to say no due to: the time it takes, the inflexibility and the price for running with your own domain being annoyingly high for a small business, I started looking for answers on your landing page. You seem to be offering just that! As a dev I can do things quick, that look good and don’t cost a lot.
5. I started reading the this HN thread and was amazed by how genuine and down to earth you seem.
All in all you just got a big fan in me. I’ll try out the prodigy, have patience with its imperfections and if you keep on communicating with the people signing up in a similar fashion to this HN thread, I think you’ll have a big amount to fans eager to push you and your product forward.
Wow, thanks! I've basically been building this in a silo so it's very nice to get such enthusiastic feedback. I am really dedicated to bootstrapping Hot Page with my own resources so that no one can pressure me to make the design more generic or somehow exploit the customers. Of course, it has not been easy doing all the programming and most of the marketing myself though. Right now we really need customers like yourself who are willing to use the beta version and provide feedback -- so thanks so much for your support!
