Your most valuable asset lives elsewhere
The source is everything the company has built. Deleting it is not something you do but something you ask for, and how long the backups keep it is decided by terms of service.
A software product by Levelupsoft Inc.
Your source code does not
belong on someone else’s server
SSemRepo is a repository your company runs itself. Repositories, issues, code review and a wiki arrive as one piece, and developers keep using the git commands they already know.
- 2
- Git and Subversion, one screen
- 10
- languages in the product
- 100%
- inside your own network
Why self-hosted
Handing over your code is handing over the company
An outside repository is quick to start with. In exchange, the design of your product and the record of who changed what, and when, piles up on infrastructure that is not yours.
When the link drops, work stops
On a closed corporate network, a factory floor or a site with no outbound access, a single clone will not go through. Some places are unreachable in the physical sense, not the policy sense.
An audit leaves you with nothing to say
When finance, healthcare or government review asks where that source is held, pointing at another company’s terms of service is the only answer you have.
Product
A repository is where it starts, not where it ends
When the place that holds the code and the place people discuss it are separate, you end up buying a second tool. SSemRepo ships all three together.
Repositories
git clone and push work over HTTPS as they are. Files, commits and diffs are read in the browser, and Subversion repositories you have carried over are read on the same screens.
Collaboration
Issues, milestones, labels and assignees; pull requests and code review; boards and a wiki. It all stays inside one project.
Operations
Groups and permissions, sign-up approval, mail notifications and templates, the site logo and backups are changed from the admin screens. Nothing here needs a redeployment.
Features
What a development team touches every day
Git repositories
Clone and push over HTTPS, branches and tags, commit lists and diffs, file browsing, web editing, forks.
Subversion as well
Revisions, files and diffs of a migrated svn repository are read on the same screens as git. Old assets do not have to be thrown away.
Issues and milestones
Labels, assignees and milestones, parent and child issues, attachments and comments, and a search that returns only what you may see.
Pull requests
Differences between branches, review comments on each file, conflict marking, merging and automatic closing.
Boards and wiki
Announcements on a board, rules and design in a wiki — with the same editor and the same attachments as issues.
Ten languages
The product speaks Korean, English, Japanese, Chinese, German, Russian, French, Vietnamese, Indonesian and Spanish.
Screens
Familiar things in familiar places
The real cost of adopting a tool is the time spent learning it. The layout follows what developers already know — projects on the left, work in the middle, code across the top.
About this screen
- The list on the left is the projects you belong to. A private project is visible only to those with access to it.
- The middle is the issue list. Narrow it by label, assignee or milestone; search looks only within what you are allowed to see.
- The tabs across the top are code, issues, pull requests, board and wiki. Each project decides which of them it uses.
Command line
Anything you do on screen, you can do from a command
What a person clicks through and what a machine repeats are not the same work. SSemRepo ships a command-line tool of its own — call it from a script, hang it off the end of a build, or hand it to a coding agent.
Nearly everything the screens have
Issues, boards, wiki, pull requests, milestones, groups, even site administration. Results come back as a table for people or as JSON for machines.
Several accounts on one machine
Keep accounts apart as profiles, and tie a directory to the account that should work in it. Below that directory it simply becomes that account.
Git authentication too
It plugs in as a git credential helper, so pushing stops asking for a password. Stored secrets are encrypted against that machine: copy the file to another one and it will not open.
Made for coding agents
Usage instructions come with it, ready to attach to an AI coding tool. “Raise this bug as an issue” becomes something that actually runs.
About this transcript
- A project is named <owner>/<name>. Set the ones you use often as defaults and leave them out.
- Creating something gives you its number back. That number is how you comment on it, change its state and assign it.
- Reading works the same way. The conditions that narrow a list are the ones the screen filters by.
Architecture
The whole deployment at a glance
Browsers and git clients arrive at the same address. The web server hands them to Tomcat; history goes into PostgreSQL and repository files stay on your own disk.
About this diagram
- Left to right: developers → web server → SSemRepo → storage. Every arrow ends inside the company boundary.
- Solid lines are the paths people use. The browser and git clone or push arrive on the same port 443.
- The lower branch is files. Repositories and attachments sit on your disk rather than in the database — a backup is a file copy.
- The dashed line is notification. It leaves only through your own SMTP, and when it cannot be sent the product does not claim that it was.
- No arrow leaves the boundary. The product runs the same way on a network with no outbound access.
Migration
Bring the repositories you already have
More teams have years behind them than are starting fresh. The git and svn repositories, issues and attachments in the tool you use today come across, with the procedure and the tools to move them.
The database
Issues, comments and history are read out of your current tool’s database and moved into PostgreSQL. Values are read through the driver and written as they are, not rewritten as text.
Repositories and files
git and svn repositories and uploaded files are copied whole, directory and all. A repository is a standard thing whichever tool it came from, so there is nothing to adjust.
Accounts and access
Users, groups and roles come along. Where the password scheme matches, existing passwords keep working and nobody has to sign up again.
Run them side by side
Before the old system is switched off, the same records are compared on both screens. You move with somewhere to go back to.
The size and schedule of a migration follow from the number of repositories and the size of the disk. Get in touch and we will look at your environment with you.
Getting started
From install to first push, in four steps
- 1
Bring the server up
Two containers — the application and PostgreSQL. All you decide is which disk the repositories live on.
- 2
Schema and first administrator
Create the tables, load the initial rows, then create the administrator account. The commands are written out in the guide.
- 3
Domain and certificate
Point your domain at it and set up HTTPS. Since git traffic passes through, the only thing to loosen is the request size limit.
- 4
Bring the team in
Decide how people sign up, then create groups and projects. If you are migrating, this is where the old material goes in.
Technology
Built to stay maintainable
Java 21 · Tomcat 11
An ordinary Java server is all it takes. Your operations team starts and restarts it the way they already do.
PostgreSQL · plain JDBC
SQL is written directly, with no heavy mapping layer in between. A slow query is found in the query.
A Svelte 5 interface
The first screen was cut down to load quickly, and even the fonts are served from your own network.
Over 1,700 automated checks
They run against a real server — creating a project, pushing to it and opening a pull request — rather than against mocks.
Considering SSemRepo?
Tell us the size of your team and what you use today, and we will propose a fit. We will help with a trial install and with migration.
Get in touchhalo@levelupsoft.com+82 10-8472-4070
Levelupsoft Inc.