# Ontime: rundown timing for live events in the browser > Ontime is a show caller for people who run live events. It keeps the rundown, the schedule and the cues, and it presents them on whichever device is in front of you, from a director's tablet to a signage screen. It runs as a cloud service, as a desktop application on four platforms, or as a container on your own network. **cpvalente/ontime** — Free, open-source time keeping for live events - Repository: https://github.com/cpvalente/ontime - Website: https://www.getontime.no - Stars: 972 · Forks: 125 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/cpvalente-ontime ## A show caller for events that run on a clock The description is short and accurate: Ontime is a browser-based application that manages event rundowns, scheduling and cueing. A rundown is the list of what happens and when, and cueing is the act of telling the people on stage and the people in the booth what happens now. In theatre, broadcast and live event production, that list is a working document that several people read at once and that has to be adjusted in real time when the running order changes, which it always does. The readme says it plainly: with Ontime you can plan, track your schedule, manage automation and cross-department show information in one place. And it says who it is for, which is the useful part. It is made by entertainment and broadcast engineers, and it is used by conference organisers, touring shows and receiving venues, broadcasters and streamers, theatres and opera houses, and houses of worship. That last category is the one that explains a lot of the design. A church service, a conference session, a theatre show and a livestream have the same underlying problem, which is a list of items with durations, a clock that must be visible to several people, and a way to say the next thing is now. A general purpose project management tool does the first part badly and the other two not at all. The rest of the readme describes the philosophy in three short sections, for live environments, for teams and for simple infrastructure, and the through-line is that the tool should fit into an existing show rather than replace it. ## Different views for different people in the room The feature list is where the design shows, and three of the items are about the room rather than about the clock. Multiplatform first: it is available as a cloud service and for Windows, macOS and Linux, or self-hosted via Docker. In any device next, because Ontime is available to any device with a browser, and the examples given are tablets, mobile phones, laptops, signage and media servers. That last pair is the important one, because signage means a screen in the room that shows the public what is happening, and media servers means a machine that plays the video. Then team collaboration, with dedicated views for directors, operators, backstage and signage. Those four are four different projections of the same state, and the fact that they are views rather than separate applications is what makes the tool work in a room where several people need different slices of the same information. Real-time updates cover the thing that actually kills live events, which is a delay. If the running order slips, everybody who is looking at a screen has to know, immediately, and the readme describes managing and communicating runtime delays as a first-class capability rather than a feature. The automation story is the fourth item and it is a design decision rather than a list. Ontime can be fully or partially controlled by an operator, or it can run standalone with the system clock. So the same application can be a timer showing the time, a timer following a schedule, or a controller for a show that another system is driving. Integrations come through the APIs, OSC, HTTP and WebSocket, or through a companion module for a video and control ecosystem, with named examples being the video mixer, the media server, the lighting board and the streaming software. ## Simple infrastructure, and four ways to install it The simple infrastructure section is short and is about the deployment rather than the application. All the data is distributed over the network, making its distribution and infrastructure flexible and cheap, and with the container image you can use existing IT infrastructure to make Ontime available online for your team and clients. The install options are unusually broad, and the list of binaries tells you what the project supports. There is a Windows executable, a macOS disk image for Apple Silicon, a macOS disk image for Intel, and three AppImages for Linux, one for Intel and 64-bit, one for ARM 64-bit which covers a Raspberry Pi 4 or later, and one for 32-bit ARM for older Raspberry Pi hardware. That last one is a strong signal about the audience. A 32-bit ARM build for an old Pi is not something a general purpose web application bothers with, and an entertainment technology tool that runs on the hardware people actually have in a rack at the back of a venue is doing something specific. There are three package routes as well. The container image on Docker Hub, an npm package for the command line, and a Homebrew cask for the desktop application. The cloud service is the easiest way to start, giving immediate access to running instances that can be shared with anyone with an internet connection, and the local route is free. Either way, once it is running, any device on the same network has access to it. ## The container, and what the ports are for The compose file and the Dockerfile are short and answer the operational questions. The compose file runs a single service with three ports published. One is a TCP port, which is the web interface and the API, and two are UDP ports, which are the realtime and control interfaces. There is a data directory mounted at a path inside the container, and a time zone environment variable, which is a detail that matters more than it looks for a scheduling tool, because every cue time in the application is in local time. The Dockerfile is a Node image on Alpine with a specific Node version, and it sets two environment variables. One flags that the process is running in the container, and the other sets where the data directory lives. The build copies the compiled client into the image as the user interface, and the compiled server plus a handful of source directories as the backend, and the entry point runs a specific server script. ```dockerfile EXPOSE 4001/tcp 8888/udp 9999/udp ``` The comments at the end of the file give the whole build and run sequence, and the run line is the one to copy: ```bash docker run -p 4001:4001 -p 8888:8888/udp -p 9999:9999/udp -v ./ontime-db:/data/ getontime/ontime ``` The two UDP ports are the ones to think about. A web-facing deployment that only publishes the TCP port will give you the browser interface and the API, and the OSC and WebSocket integrations will not work, and that is the difference between a timer on a screen and a timer that can drive a show. ## A monorepo with an Electron shell and a web client The repository layout shows a project that is a web application with a desktop wrapper rather than a native application. There is an apps directory holding the client and the server, a packages directory for shared code, and separate directories for end to end tests and documentation. The build is driven by Turborepo over a pnpm workspace, and the scripts in the manifest are all Turbo passthroughs for development, building, linting and type checking, with the distribution targets for Windows, macOS and Linux filtered down to the Electron package. That is the whole architecture in one line. The server and the client are ordinary web code, and the desktop application is an Electron shell around them, which is why the same features are available whether you run the container or the installer. The end to end tests are Playwright, with a project codegen command for generating the selectors, and a separate command to clear the temporary fixtures the tests leave behind. Unit tests are run through Vitest. The formatting and linting use two newer tools, one for formatting and one for linting, and the linting configuration is a separate file from the formatting one, which is a small sign of a toolchain that has been modernised rather than assembled at once. The runtime requirements are pinned tightly, with Node in the twenties and pnpm in the eleventh major, and the package is marked as an ES module with the version kept in one place. ## Project state, community and how to get help The release history shows a project shipping regularly, with version 4.14.0 in late September 2026, 4.14.1 in early October and 4.15.0 on the 18th, and the last push on 2026-10-19 with the repository not archived. The readme says the project is under active development and that they continue adding and improving features in collaboration with users, and it asks for ideas by email or through a new issue. There is a hosted service and a self-hosted option, and the readme is clear that the project improves from the collaboration with its users and would like to understand how you use it. The support routes are three, and they cover the range of questions people actually ask. There is documentation that aims to cover most topics, and if your question is not covered you can fill in a bug report in an issue, ask a question in the discussions, or hop into the chat server. There are also video tutorials, which for a tool with this many roles and views is arguably the more useful documentation, since a show caller is a thing you learn by watching somebody use it. The contribution guidance is specific and worth repeating for anyone thinking about sending a pull request. If you are a developer and would like to contribute with code, please open an issue to discuss before opening a pull request, and the project setup is documented separately in the development document. The licence is the GNU GPL version 3, and there is a separate file describing the terms of donations, along with a sponsor link and a one time donation option. The readme is careful to say that a donation is either support for development or a thank you, which is a distinction that a lot of sponsorship pages do not make. ## Conclusion Ontime suits a venue, a conference or a production company that runs the same timing cues on several screens and needs the operator, the director and the signage to be looking at the same thing, because that shared state is what the application is built around. It is a poor fit for a single-person event with one screen, and a poor fit if you need the timing to drive external hardware directly, since the integrations are one-directional in practice. Before you deploy it, decide between the cloud service and a self-hosted container, and check the port requirements, because the OSC and WebSocket interfaces need UDP ports exposed that a plain web deployment would not have. ## FAQ ### What is Ontime used for? It manages event rundowns, scheduling and cueing for live events. The readme says it is made by entertainment and broadcast engineers and is used by conference organisers, touring shows and receiving venues, broadcasters and streamers, theatres and opera houses, and houses of worship. ### How do I install Ontime? Download a build for your platform, which covers Windows, macOS on both Apple Silicon and Intel, and Linux as AppImages for Intel, 64-bit ARM and 32-bit ARM, or use the container image on Docker Hub, the npm package for the command line, or the Homebrew cask. There is also a hosted cloud service, and once it runs any device on the same network can reach it. ### Which ports does Ontime need? One TCP port for the web interface and the API, and two UDP ports for the realtime and control interfaces. The compose file publishes all three, and the container image exposes the same set, so a deployment that publishes only the TCP port will have the browser interface but no OSC or WebSocket integration. ### Can Ontime integrate with other show control software? Yes, through the APIs it provides, OSC, HTTP and WebSocket, or through the available companion module, which the readme names as supporting workflows built around vMix, disguise, Qlab and OBS. It can also be driven by an operator or run standalone against the system clock. ## Sources - [cpvalente/ontime on GitHub](https://github.com/cpvalente/ontime) - [Issues](https://github.com/cpvalente/ontime/issues) - [Project website](https://www.getontime.no) - [README](https://github.com/cpvalente/ontime/blob/master/README.md) - [Releases](https://github.com/cpvalente/ontime/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cpvalente-ontime