The flexibility of the Slack platform means you can self-host the apps you build or allow Slack to do the heavy lifting of hosting and data management—whichever option fits your business needs.
The newest evolution of Slack apps, workflow automations, are Slack-hosted on something we call Run On Slack Infrastructure, or ROSI for short. This guide explains the ins and outs of ROSI.
ROSI enables teams to build and execute custom workflows directly within Slack, leveraging the platform's infrastructure to streamline their processes and automate their work. ROSI aims to make it significantly simpler to host and maintain Slack integrations by providing tooling and APIs that enable developers to quickly and securely develop custom Slack integrations.
The architecture powering ROSI is built on a JavaScript and TypeScript server-side runtime environment, called Deno, and Amazon Web Services (AWS) infrastructure leveraging serverless best practices and capabilities. This enables developers to build and use modular building blocks in flexible solutions that can be easily updated as business needs change.
ROSI provides a secure and efficient way for developers to host and execute their custom code by utilizing AWS Simple Storage Service (S3) buckets and AWS Lambda. Developers can upload their code to an S3 bucket using a secure pre-signed URL that is generated by the platform. This ensures that the code is transmitted securely, protecting sensitive information and intellectual property. Once the code is uploaded, it can be executed using AWS Lambda, which provides the necessary compute resources for running the code. This combination of AWS S3 and AWS Lambda provides developers with a cost-effective, secure, and scalable hosting solution that can be adjusted based on the needs of their applications.
ROSI leverages DynamoDB to back app datastores for use during workflow executions on Slack. DynamoDB is a NoSQL database service provided by AWS. By integrating DynamoDB into the platform, developers can persistently store and retrieve data from the database during workflow executions, allowing for dynamic and data-driven workflows.
Datastores offer:
Datastores are not:
➡️ Read more about datastores in our datastore documentation.
➡️ See a datastore in action with the Announcement bot tutorial.
ROSI utilizes a sandboxing approach based on the server-side runtime, AWS Lambda, and Service Control Policies (SCP) to support environment segmentation. This results in a single-tenant architecture that guarantees that application code is not shared across tenants, promoting security and privacy.
ROSI adopts a multi-account strategy to optimize resource management, cost allocation, security, and compliance. This streamlines the overall process and ensures a better overall user experience.
ROSI currently offers developers a server-side JavaScript and TypeScript runtime environment. It is designed to deliver a secure and modern runtime environment for executing JavaScript and TypeScript code. It includes capabilities for managing sensitive resources (like the file system and network access) and reducing the risk of malicious scripts accessing these resources, ensuring a safe and secure environment for organizations to execute their code. Each Slack application gets an isolated runtime environment to ensure customer data remains isolated and secure.
To enhance the debugging and monitoring capabilities for developers on the Slack platform, Slack-hosted apps offer a developer-oriented activity and logging feature. These logs serve as a valuable resource for auditing the executions of specific application activities, such as workflow and function executions, while also capturing any logs generated within the user's functions. This empowers developers to effectively monitor and debug their applications built on the Slack platform. Additionally, developers have the flexibility to include their own logging as needed, further facilitating the debugging process.
The logs are stored for a period of 7 days and can be accessed through the Slack CLI with the slack activity
command. This command utilizes the apps.activities.list
API to provide access to the logs. This method provides details at the workflow execution and function execution level and can be filtered by severity, timeframe, trace ID, etc.
To access the Slack platform, developers must first download and authenticate through the Slack CLI. Only authorized users can log in with the CLI, and Slack Admins have complete control over who is allowed to deploy.
When a user runs the slack login
command, an API endpoint generates a temporary authentication ticket that expires after five minutes. The user must then paste this ticket into the Slack client to receive an "xoxp" token with scopes that allow for creating, reading, updating, and deleting apps and datastores where the user is listed as an owner or collaborator. In return, Slack provides a challenge code required for the Slack CLI to complete authorization.
The "xoxp" token used by the CLI has a time-to-live of 12 hours and must be refreshed using the provided refresh token. This token only provides access to the app's datastore and does not include access to Slack messages or other data. The Slack CLI will automatically refresh this token as needed. You can then install or request the installation of the app, assuming Admin-Approved Apps are enabled.
Developers integrating their apps with third-party systems often use APIs as the primary means of integration. To simplify and secure the integration process, the Slack platform has implemented a feature called third-party authentication. With an abundance of external systems and APIs that can be used in a Slack app, the industry has adopted OAuth2 as a standard protocol to streamline the authorization process. This feature relies on OAuth2 for authentication. When a developer is creating a workflow, they can authenticate with the third-party service, and this authorization will be used during the execution of the workflow when API calls are made to the external service.
➡️ Check out our tutorial on setting up external authentication via OAuth2.
The Slack platform provides enterprise readiness features designed to provide the security, compliance, and scalability required by large organizations. With these features, organizations can ensure that their data is secure and their systems are in compliance with regulations.
With Slack EKM, customers can use their own keys—stored in Amazon’s Key Management Service (AWS KMS)—to encrypt data. Administrators can revoke key access granularly, so teams experience minimal disruption. They keep working as usual, and so does Slack. All customer data used in the platform is encrypted. EKM customers have the additional benefit of encrypting their sensitive data with their own EKM keys.
EKM enables an added layer of security for customers by allowing them to manage their own encryption keys. This ensures that only authorized users can access the encrypted data and helps to prevent unauthorized access to sensitive information. The use of enterprise key management also helps to ensure compliance with regulations such as HIPAA, which require secure management of encryption keys.
Additionally, enterprise key management provides a way for organizations to maintain control over their encryption keys. By making minor updates to their AWS key policy, customers can utilize the full potential of EKM for the data elements in the Slack platform. The table below lists all of the data elements supported by the Slack platform and their respective encryption support.
Data elements | Encrypted with EKM | Encrypted with Slack/AWS key |
---|---|---|
Message metadata payload | ✅ | - |
App datastore | ✅ | - |
Developer logs | ✅ | - |
EKM custom key scopes | ✅ | - |
Third-party auth | ✅ | - |
Developer secrets | ✅ | - |
Function/workflow execution payloads | ✅ | - |
Backup/restore for app datastore | ✅ | - |
Application code bundles | - | ✅ |
App name | - | ✅ |
Function name | - | ✅ |
Datastore name | - | ✅ |
Datastore attribute (column) name | - | ✅ |
International Data Residency (IDR) is a feature in Slack that allows organizations to choose the geographic location where their data will be stored. This benefits organizations that are subject to strict data privacy and security regulations, as it allows them to store their data within the jurisdiction of their own country. IDR also helps organizations to meet their regulatory requirements and maintain control over their data, even as it moves to the cloud. By choosing the location where their data is stored, organizations can ensure that their data is subject to the privacy and security laws that are most relevant to their needs. This can provide peace of mind and help organizations to comply with regulations, while also ensuring that their data is secure. The Slack platform supports IDR for following data elements.
The Slack platform has earned several compliance certifications to show its dedication to enterprise readiness and secure operations. These certifications show that Slack has undergone thorough independent evaluations and has met rigorous security, privacy, and data protection standards. With these certifications, Slack assures its customers that their data is secure and their privacy is respected. These certifications can assist organizations in meeting their own regulatory requirements and reducing the risk of data breaches and security incidents. Currently, the Slack platform supports the following compliance certifications and is actively working to add more in the future.
✨ Get started on creating Slack-hosted apps by checking out our workflow automations documentation.
✨ Or perhaps you'd like to dive right in with a tutorial for an app that gives your comarades kudos.