Pleasanter: a no-code platform for internal business systems

A platform for the systems nobody wants to build

Pleasanter is an open source .NET based development platform for building business applications with no-code and low-code approaches, and the list of what it is meant to replace is the most useful sentence in the readme.

The systems it is aimed at are a CRM, a sales force automation tool, an issue tracker, a project management system, a document management system, and an image database. Those are the applications that a company writes for itself, that fit nobody's product, and that end up being maintained by one tired person for a decade.

The approach has two halves. The no-code half is where the application is configured: the data model, the screens, the workflow, the permissions. The low-code half is where the configuration stops being enough, and you write a script, call an API, or drop into SQL.

The readme states the extensibility model plainly: the platform provides extensibility through scripts, APIs, and SQL, enabling integration with existing enterprise systems. That sentence is the reason to consider a platform like this at all, because the integration requirement is the one that usually kills an internal tool built in a low-code tool.

The project is AGPL-3.0 licensed, the site is pleasanter.org, and the release history shows a steady 1.5 line, with 1.5.9.0 in October 2026, 1.5.8.1 in September, and 1.5.8.0 earlier that month. The last push was on 2026-10-19, so this is an actively maintained platform rather than an abandoned experiment.

The feature list, grouped by what a business asks for

The readme groups the features into seven areas, and reading them in that order tells you what the platform is actually good at.

Application development covers the no-code business application development, the low-code customisation using scripts, and the REST API for integration.

Data management is the core, and it is worth being precise about it. The data model is table based, with table relationships, data history tracking, and status management and workflow. So the platform stores data in tables the way a database does, records the history of the rows, and has a status column with a workflow attached to it. That is a business application's data model rather than a document model's.

Visualization is the part that decides whether an internal tool gets used. There is a calendar, a Gantt chart, a burndown chart, timeseries, crosstab, a Kanban board, and an image library. That is a list of the views a project manager or a sales lead actually asks for by name.

Collaboration is email notifications and chat integration with Slack and Teams among others, which is the minimum for a tool that people are expected to live in.

Internationalization lists seven supported languages, English, Japanese, Chinese, German, Korean, Spanish, and Vietnamese, and the order is telling: the first three are the markets a Japanese vendor with a Chinese speaking customer base cares about.

Extensibility then lists the four extension points, front-end JavaScript and CSS extensions, server-side JavaScript extensions, SQL extensions, and API integration. Server-side JavaScript is the unusual one, because it means a behaviour can be added without a .NET deployment, which is what makes the low-code half of the promise work in practice.

Access control at the table, the row, and the column

The security section is the one a platform like this is judged on, and the list is specific.

Access control works at three levels: table, row, and column. Table level is the coarse one, a user can see the table or not. Row level is what lets a manager see their own department's records and not their colleague's, and it is the level that makes a shared table safe to use for anything sensitive. Column level is the third, and it is the one that lets a table hold a field that only some roles may read.

Then there are four authentication methods. LDAP authentication, which is what an existing company directory gives you. SAML authentication, which is what a single sign-on service gives you. Two-factor authentication, for the second factor on top of whichever of those you use. And passkey authentication, which is the newest of the four and the one that removes the shared secret problem from an internal tool that many people log into every morning.

Having all four in one product is the point, and it is the reason the platform can sit inside an existing enterprise without asking the security team to invent a new way in. An internal tool that stores customer records cannot ask its users for a second password when the company already has a single sign-on.

The requirement table underneath is short and constrains where the thing can run: Windows or Linux as the operating system, .NET 8 or .NET 10 as the framework, and SQL Server, PostgreSQL, or MySQL as the database. Three database engines is a generous range for a platform with this much behaviour, and it is the range that decides whether it can be adopted where the data already is.

The Docker path, and the three connection strings

The getting started section is written for someone evaluating the platform on a laptop, and the whole thing comes down to two files and a sequence of four commands.

You create a directory named pleasanter and put two files in it, an environment file and a compose file. The environment file carries the database settings and, more interestingly, the three connection strings the platform needs, and they are not the same connection string.

There is a super user connection, which is the one that owns the database, and the placeholders in the example are the database name, the user, and the password. There is an owner connection, whose database name is a placeholder that expands to the service name, with a user that expands to the service name plus an owner suffix. And there is a user connection, with the same pattern and a user suffix. The service name is substituted at run time, which is how one image serves many installations.

The compose file then has three services. The database is the PostgreSQL image with a volume and a health check that runs the readiness command against the configured user and database, checking every ten seconds, with a timeout of five, five retries, and a thirty second start period. The platform service waits for the database to be healthy, not merely started, and publishes port 50001 of the host to port 8080 of the container. And the schema initialiser is a third service from the same image family, which exists only to run the initialisation step and exit.

Waiting for health rather than for the container to exist is the detail that makes this work on a first run, because the database takes a few seconds to accept connections and the initialiser would fail against a database that is running but not ready.

CodeDefiner, the step that creates the schema

The initialisation step is a separate container, and it is the part of the sequence that is easy to skip and expensive to skip.

First the images are pulled, and then the schema is initialised by running the CodeDefiner service with the database flag, a language, and a time zone. The placeholders in the readme show the shape of the command, and the language and the time zone are the two things you set for your own installation, since they determine the language of the interface and the time zone the platform writes dates in.

The same command has a flag that suppresses the prompts, and the example passes the language and the time zone with that flag, which is the version to use in a script or a pipeline where nobody is there to answer a question. The three commands in the middle of the sequence are the ones the readme shows.

    docker compose run --rm codedefiner _rds /l "{{Language}}" /z "{{Timezone}}"
    docker compose run --rm codedefiner _rds /l "ja" /z "Asia/Tokyo" /y
    docker compose up -d pleasanter

Then the platform is reachable on the local port, and the readme prints the default login, with the administrator account and its password, and then tells you to change that password after the first sign-in for security reasons.

That default credential is the one thing in the whole getting started section worth pausing over. It is published, it is the same for every installation, and a platform that stores business data behind a table and row level access control is exactly the kind of system where an unchanged default is a real exposure. The readme says to change it, and the practical advice is to change it as part of the deployment rather than afterwards.

Stopping the system is a single compose command, and the demo is the other way to see the product, where you register an email address and try it, which is available in Japanese only.

The repository, and the licence that comes with it

The repository layout is a .NET solution with a name for every concern, which is a readable way to understand a platform of this size.

There is the main application, a separate frontend project, the code definer that owns the schema, and a set of accessor projects with names that describe their role: a definition accessor, a display accessor, a parameter accessor. There is a factory, a libraries project for shared code, a plugins project, and a test automation project. The Rds directory holds the database related code, and the solution file ties it all together.

The split into the frontend, the display accessor, and the parameter accessor tells you that the platform separates what the user sees, what it can configure, and what it can be given, which is the structure a multi tenant business application needs and a simple application framework does not.

The plugin project and the libraries project are the two extension points that matter most, because they are where a deployment adds its own behaviour without forking the platform.

There are two compose files. The one in the repository builds the images from the Dockerfiles in the application and the code definer directories, and it is what a developer uses, while the one in the readme pulls published images, which is what an evaluator uses. That distinction is why the readme's compose file names its images explicitly and the repository's does not.

There is also a licences directory, a global configuration file pinning the .NET SDK, and a directory for the release documentation and the Docker build project. The licence itself is AGPL-3.0, which for a platform that sits inside a company and stores its data is a decision to check before deployment rather than after.

Editorial conclusion

Pleasanter fits a business that keeps its internal tools in spreadsheets and small custom systems, and that wants a platform where the schema, the workflow, the permissions, and the screens are configured rather than coded. It does not fit a team that wants a general purpose application framework, because the platform is opinionated about being a business application builder, and it does not fit a deployment that must avoid running a .NET application server. Verify first that your platform is in the supported list, which covers Windows and Linux with .NET 8 or .NET 10 and three database engines, that the three database connections the platform expects are understood by whoever operates the database, and that the administrator password is changed immediately, because the evaluation path ships a published default one.

Frequently asked questions

Official sources

1. Implem/Implem.Pleasanter on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases