Replies: 7 comments 14 replies
|
ARM-64 support would be awesome |
|
@camflan do you mean linux arm64? |
|
Multi-node / High Availibility is game changer for me |
|
for one, should be a tad easier to spin up a test env tried the script but requires a domain. Just wanna test it without setting up a domain and dns records tried it manually but when starting i get: Error: Failed to start proxy server: Failed to register GeoPlugin: Plugin registration failed for 'geo': Other error: Failed to open MaxMind database at '/xxxxxx/GeoLite2-City.mmdb': i/o error: No such file or directory (os error 2) so i gave up |
|
Hi @lostb1t thanks for the feedback For the domains, I will add the reason why we require a wildcard domain to the deploy.sh script. It's a one time operation needed to be able to deploy any future application without manual work for each domain. I understand it's an extra step that Coolify/Dokploy doesn't have, but in return it allows you to move fast with multiple projects/environment with a closer experience to Vercel/Railway/Render. About the GeoPlugin error, it will be fixed in the next release (already available in v0.1.0-beta.16) to auto download |
|
i understand the reason, like i said, when coming across a new project like this inwant to spin it up fast and just be able to test basic functionality / browse the ui without having to setup a domain and necessary dns redords for deployment as its just testing. Lots of similar projects dont make this a requirement for setup and just allow setting it during runtime. just my 2 cents |
|
Would a hosted read only demo help? Or optional domain setup when setting up temps |
yeah for sure |
|
Something like crowdsec builtin would be nice (optional ofcourse) think pangolin has it aswell |
|
I use hetzner servers for container stuff and Cloudflare for the things that can’t run on Cloudflare and need fast edge . There might be opportunities for some integration aspects . Maybe a plugin or just docs |
|
Deployments & environments |
|
I'm working on improvements to make deployment of temps 10x easier and also deployment easier. What version are you running? |
|
@dviejokfs I ended up switching to Dokploy for now. However, I still think your platform has a lot of advantages, so I'm looking forward to a significant update from your side. The main blocker for me at the moment is support for deploying projects that are already defined as raw Docker Compose stacks, similar to what Dokploy supports. As soon as I can deploy those projects directly, I'd be happy to move back. |
|
version 0.1.0 will make the experience of getting from 0 -> 1 way faster. I'll post here as soon as that happens so that you can give it a try. |
The integrated, out‑of‑the‑box support for features that would normally have to be purchased and integrated into each application has required a huge time investment. For short‑lived campaign projects at marketing and experiential agencies, where digital applications must be deployed within a few days to weeks and remain active only briefly, budgets are already tight for both third‑party services and development. Nevertheless, analytics, funnels, error tracking, and session recordings are expected features for every build.
Since Temps is currently in beta, I am experimenting with personal and previous digital campaigns. I plan to host a live campaign using Temps in the near future, alongside the standard Vercel plus third‑party setup for redundancy.
The out-of-the-box support for features such as error tracking, session recording, and analytics is amazing.
Build reliability. Initial testing with personal and previous digital campaigns showed that the deployment failed, whereas it succeeded on Vercel. Additional debugging time was required to determine how to achieve a deployment. The project configuration needed to be adjusted. RBAC/teams scoped to projects is essential. Granting a team member full access to all projects on the self‑hosted version of Temps is undesirable. While Temps self‑hosting offers enough features for studios and agencies, the absence of project‑scoped role‑based access is a critical shortcoming that could hinder adoption. Consequently, the platform would likely be limited to hobby projects, reducing the pool of developers willing to contribute. Many of the features in Temps are dashboards that are typically maintained or owned by a third party (e.g., a client). If I wanted to grant a client access to these dashboards, most notably the analytics/funnels dashboard, I would have to give them access to my entire suite of hosted projects. This feature alone would be a determining factor as to whether I would adopt Temps. Of course, this is from the perspective of running a studio. However, I believe that RBAC or some level of user access control to projects would be a major factor in deciding whether Temps is software to consider.
|
|
RBAC/teams for self hosted are in the premium version @brunyeestudio which I think it makes sense as a monetization strategy for temps, pricing is still to be decided |
I understand your need to monetize, however, I don’t see gating RBAC/teams on self‑hosted as creating paying customers, but rather as non‑adopters. A developer or studio capable of self-hosting Temps is exactly the audience who will notice the limitation immediately, and exactly the audience with the skills to do something about it other than pay. Without it, a self-hosted instance can't be used with more than one person or client safely, so it's a hobby-project tool, full stop, for anyone with the technical ability to host it themselves. That approach is not a monetisation strategy, it's a wall that keeps out the self-sufficient developers who'd otherwise become your best advocates. This is not a hypothetical either, it is a documented pattern... Terraform -> OpenTofu, Redis -> Valkey, Elasticsearch -> OpenSearch. All three gated features that users needed for basic functionality, rather than truly premium ones, and this likely failed because, in the Redis case, they reverted their license. Regarding revenue, it simply promoted a competing product created by the people they tried to charge. Temps is MIT/Apache-2.0, which offers less protection than the ones listed above, so a fork here isn't a wild idea. My 2 cents is on where I think the actual leverage is instead... First, advocacy. A developer who self-hosts Temps and gets the full feature set for free is the person who tells their team, their agency, their next client project to use it, precisely because it worked for them without compromise. That advocacy is worth more than anything an RBAC paywall generates, but it only happens if the free version is actually complete. The real cost of self-hosting isn't a missing feature, it's owning build reliability, patching, backups, and uptime yourself. That's the genuine tradeoff pushing people toward paying, and it's a stronger lever. Second, pricing. I'd build this around a single Cloud offering, not a tiered ladder of gated features. One SKU that includes everything a managed cloud product is supposed to include: SLAs, managed updates, backups, security patching, maintenance. The pitch being "sign up and forget it exists". You're selling the fact that the customer never has to think about ops again. That's simpler to sell and is a common pattern, as you likely know. Third, the feature set alone should carry the price. Analytics, funnels, session replay, error tracking, and deployment in one binary is genuine gold dust, and it's valuable enough on its own that people will migrate to Temps just to stop juggling four or five separate subscriptions. That means Cloud can charge a real premium and still be a clear net saving compared to Vercel plus Sentry plus PostHog plus everything else it replaces. You don't need to withhold features to justify the price. The bundle already justifies it. These are just my thoughts... |
The projects I'm testing are under an NDA, so I cannot share them. However, I will continue to raise issues, and if I have a public repository I can demo, I will be sure to share it. |
|
yeah you are right on that, I was a bit defensive on that one. But for the past week thinking about how to monetize it, I think the bundling approach makes sense specially in the cloud, since it can be as expensive as the rest combined (in theory) and still provide value due to the time saved between integrations. btw the project might be renamed to "autoship" later this year since temps will pivot to build self driving products closing the loop of observing, proposing and applying changes to the products based on the data on the platform (analytics, session replays, opentelemetry, metrics, logs, etc). If you got any ideas happy to hear them. Expect a PR in the next days for the RBAC for users |
|
Oh, that's awesome to hear! I fully understand the magnitude of adopting a different monetisation approach, especially when hearing it from users who could easily be seen as "wanting more for less". However, from my perspective, Temps in the cloud is worth the investment because it saves time on both self‑hosting operations and integrations. Regarding the pivot, it would be interesting to see it in action. I will share any ideas once I understand the direction through implementation. |
Uh oh!
There was an error while loading. Please reload this page.
Hey everyone 👋
We're building Temps to be the self-hosted platform that replaces your deployment stack, analytics, error tracking, session replay, and monitoring — all in a single binary.
We'd love to hear from you to make sure we're building the right things. If you've tried Temps (or are considering it), drop a comment answering any of these:
1. What brought you here?
What made you look into Temps? Cost, self-hosting, simplifying your stack, something else?
2. What are you running on it?
Side projects, production apps, internal tools? What kind of stack (Next.js, Go, Docker, etc.)?
3. What's working well?
Anything you particularly like about the experience so far.
4. What's missing or frustrating?
Rough edges, missing features, things that made you consider going back to another tool. Be honest — this is the most useful part.
5. What should we prioritize next?
If you could pick one area for us to focus on, what would it be?
No format required — just comment with whatever is on your mind. Short answers are perfectly fine.
Thanks for being early users. Your feedback directly shapes what we build next.
All reactions