Features

Free or Discounted Personal Rewst Instance for Devs/Engineers
It would be extremely valuable to offer Rewst instances for personal, non-commercial use by developers and engineers at organizations actively using the platform. A few key reasons this makes business sense: Stronger Internal Champions: When team members get to explore Rewst organically outside of structured work hours, it deepens their connection to the platform. This personal engagement often translates into stronger internal advocacy when an organization is evaluating whether to continue with Rewst or explore alternatives. In contrast, if those same users are also familiar with other platforms (e.g., n8n, Power Automate) because they can experiment with them freely at home, it puts Rewst at a disadvantage. Accelerated Onboarding for New Clients: New orgs are more likely to see faster time-to-value when their team includes devs who’ve had the opportunity to tinker with Rewst outside of a business context. Many of the people who naturally excel at building in Rewst are tinkerers at heart — when given the freedom to explore, they almost always will. Encouraging this kind of unstructured experimentation fosters faster learning, deeper comfort with the platform, and a stronger overall automation culture within the organization. Intrinsic Motivation Fuels Adoption: Speaking from personal experience — I likely would have ramped up far faster in Rewst had I been able to experiment with it for personal projects. Now that I’ve spent meaningful time in the platform, I want to use the skills I’ve developed beyond work-specific automations. Encouraging that level of personal investment strengthens the bond between your users and your platform. To manage cost and ensure fair usage, instances could be limited in execution volume, frequency, or concurrency — just enough to prevent abuse or strain on infrastructure while still being incredibly useful to the average automation enthusiast. This isn’t just a perk for devs — it’s a long-term growth strategy. Rewst becomes more than a tool we use at work — it becomes the one we prefer to use everywhere. —Sincerely, A guy who just spun up n8n at home only because I couldn’t do the same with Rewst 😅
4
Adding a 3rd tier to Organizations in REWST
As I dive deeper into the mystical realms of REWST organization structures, I’ve had a revelation—nay, a vision! What if we added a third tier to our hierarchy? Picture this: Parent Organization – The mighty MSP overlord, the all-seeing eye, the supreme ruler of the REWSTiverse. Child Organization – The client, loyal subject of the Parent, but with a rebellious streak and a penchant for independence. Grandchild Organization – The customer sites. These are the wildcards. The rogues. The Han Solos of the REWST galaxy. They follow the rules... unless they don’t. Why a Third Tier? Because reality is messy. Tools like RMM, Auvik, and other site-specific applications don’t always play nice when everything is lumped into one big happy family. Sometimes, you need to say, “Hey, this config is just for Site A, not the whole dang client!” With a Grandchild tier, we can: Assign tools and integrations at the site level. Keep configurations clean and scoped. Avoid the dreaded “Why is this alert firing for every site?” scenario. The Power Dynamic Let’s talk governance, because every good empire needs rules: Parent Org: The Emperor. Sets the laws of the land. All defaults, flows, and variables cascade from here. Child Org: The Governor. Can override the Emperor’s laws with local edicts (a.k.a. variables and flows). Grandchild Org: The Rebel Base. They do what they want. If they define their own variables or flows, they take precedence. If not, they fall back to the Child, and then the Parent. It’s like inheritance, but with more drama. TL;DR: Let’s build a third-tier org structure in REWST: Parent → Child → Grandchild. It’ll make tool integration cleaner, governance more flexible, and give us the power to manage chaos like pros.
2
Load More