4
19 Comments

Idea validation: Running scripts from Slack

Hi community,

I'm currently working on a tool to run coded scripts from Slack.
It's called Skriptex (available at www.skriptex.io).

That's something you can invoke in any slack channel, running the command: /skript, and it shows up like this:

  1. A menu to manage all your scripts

  2. An interface to code, in different languages (currently Python, Javascript and Ruby)

You can use it for many purposes, from system administration to customer support, business process automation, or any other thing.

And, I would like to know, as this is something quite flexible and generic:

  • Is that something that talks to you?
  • Could you easily imagine a few things that you'd dream to automate in Slack?
  • Regarding how the tool works, would you feel confident writing a script in it?

In general, any feedback is welcome, about anything: the idea, the design, the name, …

Just drop all what you think. I'm very eager for your feedback :)

posted to Icon for group Ideas and Validation
Ideas and Validation
on May 11, 2020
  1. 3

    I like the idea, I think it can be useful, even more, if you can collaborate with other's people scripts

    1. 1

      Thanks for the feedback.
      Indeed, that would add great value. But, do you think you could live without the collaboration feature?

      1. 1

        Absolutely, I think you don't even need 3 different languages.

        What you have seems enough for a MVP.

  2. 2

    I like the idea, can you expand upon how the scripts are defined and where they reside? There are lots of Slack bot type solutions such as Hubot they all require setting up and hosting the bot. I'd suggest your best angle would be to become "the Heroku of Slack bots" with a very simple way to build, define, and deploy scripts that can be executed in Slack.

    Another big part of it is going to have to be permissioning. Beyond the smallest of teams, companies will want to allow only certain people to run certain scripts.

    1. 1

      Great answer. Many good ideas. I'll take inspiration from it. Thanks a lot.
      Just a question about your idea "Heroku of Slack bots": did you use this phrase to illustrate your suggestion, or the idea "Script from Slack" was not very clear for you?
      Best,

      1. 1

        "Script from Slack" is clear to me but this already exists in the form of plenty of scripts that people build in house and maintain the infrastructure for themselves. I think the magic in the idea is a system that abstracts all of that maintenance away from you and basically connects a Git repo to a lambda function in the cloud to your Slack along with a web UI and CLI to manage.

  3. 1

    BPA and RPA: What’s the difference
    Business process automation (BPA) is the technology-enabled automation of complex, end-to-end business processes. Unlike Robotic Process Automation (RPA), which focuses on automating individual tasks within a process, BPA involves the orchestration of multiple tasks and processes to achieve the desired outcome.
    Find out in this blog a complete guide to start your BPA journey: https://bit.ly/3Igi043

  4. 1

    I suppose it would just be a case of how easy it would be to implement. This kind of thing is already possible through other vendors and Slack integration hooks. Would you write the script directly in slack?

    1. 1

      Hi, I'm not sure that other vendors will provide the same functionality to run any kind of scripts from slack. It's not about creating bots, but, really anything else : SQL analytics, …, and yes, you can write from slack

      1. 1

        Yeah, so I'd definitely do some research into who would actually use it. I'm a technical lead and wouldn't like my team directly using scripts within slack as it leaves too much open to human error which could do serious harm depending on what it is.

        It may work for smaller businesses using slack however. We have processes already set up for anything script based to just run as a process script. Doesn't mean that can't be made better though.

        I suppose I'm just trying to figure out a use case in my head where I'd want that functionality. As most useful scripts would need some API to talk to then you have issues with CORS and such.

        1. 1

          Awesome. Thanks for the comment.
          So, you would be ok for launching scripts from a web UI, but not from a slack command?

          About the last point, I'm not sure I get it: communication is done from server to server, so, there is no problem with CORS. Am I wrong?

          1. 1

            So if they are running it directly from slack, it is running from there UI, not a server. Slack used to be written in electron which is essentially a hosted web app, so it is highly likely CORS will become a problem.

            Yes, we constantly launch scripts from a Web UI for all our CI/CD processes, etc. A slack command is different to writing scripts in slack. I wouldn't mind commands to trigger scripts in a managed location

  5. 1

    Hi Alexis,

    I like the idea. There are other players in the space, so perhaps you should find a niche where Skiptex can consistently beat the competitors. "flexible and generic" is good, but being focused on solving a single problem is good too.

    You'll also need convince teams to use Skriptex instead of some of the capable open-source bots out there (hubot, errbot, etc).

    For me a big concern would be security. If this is used for sysadmin, does getting access to a company slack channel mean I can mess with servers? Your server security then becomes as secure as your chat.

    For me to consider writing a script with Skriptex, it'd also have to have some kind of version control.

    Also check out Stackstorm - it's a huge automation platform with a large chatops component. https://docs.stackstorm.com/chatops/chatops.html

    Another use case I can see for this is learn-to-code channels / coding bootcamps. Posting code examples right in the chat could be a pretty good teaching tool.

    1. 1

      Hi, thanks for the feedback.
      I think you're raising two important points.

      1. About the competitors, maybe that the branding is not correct: we don't aim to provide a solution to help people building bots (like hubot, etc…). We focus on running scripts instead. Is that something not very clear?
      2. About security, for the moment, you can only run your own scripts. So, that's not a big problem.
      1. 1

        About the competitors, maybe that the branding is not correct: we don't aim to provide a solution to help people building bots (like hubot, etc…). We focus on running scripts instead. Is that something not very clear?

        The pitch on the website is really clear, I just mean that these bots are able to run scripts too. It's quite simple to a slash command to get hubot to run a script.

        About security, for the moment, you can only run your own scripts. So, that's not a big problem.

        I mean security within the channel. If I wrote my own script called '/restart_database', I definitely wouldn't want marketing, junior devs, and others in the Slack channel to be able to run it, just sysadmins. Hope that explains what I mean.

        Good luck with Skriptex, I'm looking forward to seeing it grow!

        1. 1

          Thanks for the compliment on the pitch.

          Indeed, I did not document enough, they are also able to make it, but you'll have to host + program much more (you can't script live).

          About security, for the moment, you can only run the script that you wrote (so, by default, they are not shared to junior devs or marketing). However, that something that we'd like to implement, but, on a manual basis: you should opt in for sharing a particular script

          1. 1

            Ah, thanks for explaining, got it. Yes, that's a lot more secure.

            they are also able to make it, but you'll have to host + program much more (you can't script live).

            I'd like to see that explicitly on the landing page, as I think "Why not hubot?" would be one of the most common objections you'll get. Skriptex saves time setting up and and managing a bot, so I think you should list that as one of the benefits.

  6. 1

    We had a tool like this where I worked that we built ourselves -- chat ops so this is a VERY strong idea. We were using it to handle our deployment processes.

    The reason it made a lot of sense is because it made deployment very transparent. You always knew what was going on and if you were a new engineer you could see the exact commands needed to get the deployment process running.

    1. 1

      So, you would use it mainly for automating deployments?
      What about the other use cases: server monitoring, etc… do you currently use something else for that (like manually written scripts hosted on some kind of servers?)

Trending on Indie Hackers
Meme marketing for startups 🔥 User Avatar 12 comments Why Building in Public Changed My SaaS Journey Forever User Avatar 10 comments From $0 to $10k MRR: My Indie Hacker Journey – Part 1 User Avatar 6 comments Protect your momentum like your life depends on It User Avatar 4 comments Don't be a Jerk. Use this Tip Calculator. User Avatar 1 comment Opsgenie vs. Splunk: Choosing the Right Incident Management Solution User Avatar 1 comment