# Upgrading Temporal service with helm

**URL:** <https://community.temporal.io/t/upgrading-temporal-service-with-helm/1265>\
**Category:** Community Support\
**Tags:** java-sdk, helm\
**Created:** [January 5, 2021, 7:54am UTC](https://community.temporal.io/t/upgrading-temporal-service-with-helm/1265 "2021-01-05T07:54:32Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![m\_p](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/m_p/32/161_2.png) [@m\_p](https://community.temporal.io/u/m_p)\
**Post date:** [January 5, 2021, 7:54am UTC](https://community.temporal.io/t/upgrading-temporal-service-with-helm/1265/1 "2021-01-05T07:54:33Z")

</div>

Hello,  
this is a bit of a continuation of [this thread](https://community.temporal.io/t/upgrading-existing-helm-charts/627) which ended with “TBD”.

I’d like to describe our current deployment and ask if we pieced the documentation together in a working upgrade solution, with some additional questions.

We have workflows implemented using java sdk version `1.0.0`.  
We have temporal service version `1.0.0` deployed from helm charts, the store is MySQL.

1. We upgrade our java sdk to `1.5.1`. (as I understand, this is not required and it could stay on `1.0.0` and would work either way)

2. We perform database schema update. This is a bit tricky to me as a manual step but as I see it we have two options:

- Build the binary with `make sql-temporal-tool` from the go source.  
The [readme](https://github.com/temporalio/temporal/tree/master/tools/sql#for-production) claims we should just `make` but is that necessary for the sql-temporal-tool only?  
After that, we would need to copy the contents of `/schema/mysql/v57` and run the individual `v1.1`, `v1.2` and `v1.3` temporal and `v1.1` visibility updates.
- The `tamporal-sql-tool` binary is already available locally in `admin-tools`, but since we don’t know if it is the latest version, we would probably still need to somehow first upgrade `admin-tools` first and mount the `/schema/mysql/v57` there.  
Or is it safe to assume that the binary has not changed incompatibly and only mounting the sql schema updates into `admin-tools` and using what is in there for `1.0.0` is OK?

1. At this point our database schema is updated and backwards compatible, meaning it does not break our `1.0.0` temporal service deployments. Is that correct?  
And what remains is the rolling [`helm upgrade`](https://github.com/temporalio/helm-charts#upgrading) itself.

Considering the questions, have I described the upgrade procedure correctly? And also, is this the recommended way to do it? Or is there a more “straightforward” way, something like the `admin-tools` performing the backwards compatible database schema upgrades when they are upgraded themselves?

---

<div class="post-metadata">

**Author:** ![Wenquan\_Xing](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/wenquan_xing/32/362_2.png) [@Wenquan\_Xing](https://community.temporal.io/u/Wenquan_Xing)\
**Post date:** [January 5, 2021, 6:22pm UTC](https://community.temporal.io/t/upgrading-temporal-service-with-helm/1265/2 "2021-01-05T18:22:34Z")

</div>

about server upgrade:

1. we currently only support 1.n.x to 1.n+1.x, since server side is going through lots of migrations.

2. when upgrading the schema, you can either pull the image `temporalio/admin-tools/<1.m.n>`, or checkout github tag `https://github.com/temporalio/temporal/tree/v<1.m.n>`

---

<div class="post-metadata">

**Author:** ![m\_p](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/m_p/32/161_2.png) [@m\_p](https://community.temporal.io/u/m_p)\
**Post date:** [January 6, 2021, 8:20am UTC](https://community.temporal.io/t/upgrading-temporal-service-with-helm/1265/3 "2021-01-06T08:20:54Z")

</div>

Thank you for the reply.

> we currently only support 1.n.x to 1.n+1.x, since server side is going through lots of migrations.

Just to make sure I understand this correctly, it is not possible to upgrade directly and the the steps to go from 1.0.0 to 1.5.1 would then need to be 5 deployments:

1. db schema update to `v1.1`, temporal helm with `server.image.tag=1.1.1` (and other images…)
2. db schema update to `v1.2`, temporal helm upgrade to `server.image.tag=1.2.2`
3. db schema update to `v1.3`, temporal helm upgrade to `server.image.tag=1.3.2`
4. temporal helm upgrade to `server.image.tag=1.4.2`
5. temporal helm upgrade to `server.image.tag=1.5.1`

?

---

<div class="post-metadata">

**Author:** ![Wenquan\_Xing](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/wenquan_xing/32/362_2.png) [@Wenquan\_Xing](https://community.temporal.io/u/Wenquan_Xing)\
**Post date:** [January 6, 2021, 6:39pm UTC](https://community.temporal.io/t/upgrading-temporal-service-with-helm/1265/4 "2021-01-06T18:39:16Z")

</div>

> [@m\_p](#):
>
> it is not possible to upgrade directly

There is nothing prevent you from upgrading directly from 1.0 to 1.5 right now.  
HOWEVER, lots of features and migrations are done to the server (e.g. support of infinite timeout)  
To guarantee there is no weird behavior during server upgrade, we currently only support 1.n.x to 1.n+1.x upgrade path.

We are working on a long term server upgrade strategy.

For your situation, I believe you can directly upgrade from 1.0 to 1.3, then 1.4 and 1.5
