(Appreciate the feedback! We clearly need to continue to improve how we explain the product. :))
It's probably easiest to explain in terms of what a developer does on Airplane:
1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.
2. Dev uses the `airplane` CLI locally to run and test the code
3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane
4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.
It's similar to GitHub actions in architecture (but for a different domain).
[0] https://docs.airplane.dev/getting-started/views
[1] https://docs.airplane.dev/self-hosting/agents
It's probably easiest to explain in terms of what a developer does on Airplane:
1. Dev writes code (e.g. see our Getting Started for views[0]) - this can be simple Python scripts, JS views, shell scripts, etc.
2. Dev uses the `airplane` CLI locally to run and test the code
3. Dev runs `airplane deploy` or pushes to GitHub to deploy the code to Airplane
4. Dev's teammate (or dev) can now visit app.airplane.dev to run the code (views, tasks, runbooks) - the execution defaults to Airplane's servers, but you can also use our self-hosted agents[1] to move the execution (data plane) to your own cloud environment.
It's similar to GitHub actions in architecture (but for a different domain).
[0] https://docs.airplane.dev/getting-started/views
[1] https://docs.airplane.dev/self-hosting/agents